From duke at openjdk.org  Sat Mar  1 02:09:15 2025
From: duke at openjdk.org (duke)
Date: Sat, 1 Mar 2025 02:09:15 GMT
Subject: Withdrawn: 8337246: SpinnerSkin does not consume ENTER KeyEvent when
 editor ActionEvent is consumed
In-Reply-To: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
References: <yoqTOAeky1RsFrsDLcNDNciCMuEFh1CzYG5LUJ_vRTk=.2ab85871-2cb8-4c90-920e-7671988b3207@github.com>
Message-ID: <NAB4J84YnY_-DmtLrk7YTEy2PfN8MNiH0yGeqp-S_OI=.84abfb3f-89ad-4a20-a6df-ac9438cdcd50@github.com>

On Thu, 7 Nov 2024 14:08:09 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This is a proof of concept fix for the linked issue.
> 
> We'll need to discuss if using an event filter in the Behavior is the appropriate fix and how much impact this may have on current applications.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx/pull/1629

From duke at openjdk.org  Sat Mar  1 04:06:04 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Sat, 1 Mar 2025 04:06:04 GMT
Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com>
References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com>
Message-ID: <53gwa9ouTh8bGYWLsXHODmhDW7e13Pbk3ycOAaziKpw=.1762114c-75b2-42bc-b28e-452f72255707@github.com>

On Thu, 12 Sep 2024 11:43:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this.

doc-files/release-notes-23.md line 11:

> 9: ## Important Changes
> 10: 
> 11: ### JavaFX 23 Requires JDK 21 or Later

why are `Requires` and `Later` capitalised?

I went back and it was also the case with [JFX 23 release notes](https://github.com/openjdk/jfx/pull/1563/files#diff-2d16210695314e7aef40df186b6428372f477736598ee49496f5340159d72fcbR11). Just curious is there a defined casing style that we follow for release notes?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1563#discussion_r1976266735

From jhendrikx at openjdk.org  Sat Mar  1 10:32:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 1 Mar 2025 10:32:59 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
Message-ID: <O74JcJXzQb3k9GGUbu14PHPErKD7sNone0GjxRnfBxg=.0b47fe6d-beae-4168-9cc9-e3cea5714bb4@github.com>

On Fri, 28 Feb 2025 15:56:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md

Marked as reviewed by jhendrikx (Reviewer).

doc-files/release-notes-24.md line 66:

> 64: See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) for more information.
> 65: 
> 66: ### Pluggable Image Loading via javax.imageio

Suggestion:

### Pluggable Image Loading via `javax.imageio`

doc-files/release-notes-24.md line 70:

> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
> 69: 
> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the IIORegistry class. Refer to the Java Image I/O documentation for more information.

Suggestion:

Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the `IIORegistry` class. Refer to the Java Image I/O documentation for more information.

doc-files/release-notes-24.md line 74:

> 72: See [JDK-8306707](https://bugs.openjdk.org/browse/JDK-8306707) for more information.
> 73: 
> 74: ### ScrollPane Consumes Navigation Keys Only When It Has Direct Focus

Suggestion:

### `ScrollPane` Consumes Navigation Keys Only When It Has Direct Focus

doc-files/release-notes-24.md line 90:

> 88: Likewise, as of JavaFX 24, it is no longer possible to run JavaFX applications with a security manager enabled. This is true even if you run your application on an older JDK that still supports the security manager.
> 89: 
> 90: The following exception will be thrown when the JavaFX runtime is initialized if the Security Manager is enabled:

I think this would flow better as:

Suggestion:

The following exception will be thrown when the JavaFX runtime is initialized with the Security Manager enabled:

doc-files/release-notes-24.md line 100:

> 98: ## Known Issues
> 99: 
> 100: ### JavaFX Warning Printed for Use of Terminally Deprecated Methods in sun.misc.Unsafe

Suggestion:

### JavaFX Warning Printed for Use of Terminally Deprecated Methods in `sun.misc.Unsafe`

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2652377958
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1976381908
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1976382334
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1976382191
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1976381703
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1976382418

From jhendrikx at openjdk.org  Sat Mar  1 10:44:31 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 1 Mar 2025 10:44:31 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <89rYaYvaFJzYlJrJtcExcIEQ6GDHYMC8O0XaWJtymSM=.929de5b1-7806-4c6b-9934-d8fa754c373e@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

@mstr2 / Dirk Lemmermann : This is a proof of concept PR for parent provided properties.  I've adapted HBox / VBox only in this PR, and I probably need to update the CSS documentation still.  I've opted to leave out the static HBox / VBox method to get these as a property (ie. `hgrowProperty`) although a property is used internally and so it could be exposed fairly easily later.  My plan is:

- Get some early feedback on the implementation, naming and the new API method in Styleable
- Decide the scope of this PR; I'd be in favor to get the core code in, then add more support later to ease reviews
   - Include new static property methods as well?
   - Include GridPane as well?
   - Any other controls?
- Add some specific unit tests for this new feature
- Update CSS docs
- Ready for review
- Integrate

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2665333665

From jhendrikx at openjdk.org  Sat Mar  1 10:44:31 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 1 Mar 2025 10:44:31 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable properties
 for child nodes
Message-ID: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>

8350917: Allow parent nodes to provide CSS styleable properties for child nodes

-------------

Commit messages:
 - Remove white space
 - Proof of concept parent provided styleable properties

Changes: https://git.openjdk.org/jfx/pull/1714/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1714&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350917
  Stats: 579 lines in 6 files changed: 368 ins; 61 del; 150 mod
  Patch: https://git.openjdk.org/jfx/pull/1714.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1714/head:pull/1714

PR: https://git.openjdk.org/jfx/pull/1714

From kcr at openjdk.org  Sat Mar  1 14:59:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 1 Mar 2025 14:59:03 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v8]
In-Reply-To: <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
Message-ID: <OfQ-pA6jcMxjO2nFXp288YhoYxakn5l4zvztAXY6Aco=.fcfe7f49-8d52-4214-a8a7-72f016fd4870@github.com>

On Thu, 30 Jan 2025 23:02:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
>> 
>> Removed earlier manual tester in favor of the monkey tester.
>> 
>> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

@arapte Please review.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2692269724

From duke at openjdk.org  Mon Mar  3 10:57:36 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 3 Mar 2025 10:57:36 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v2]
In-Reply-To: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
Message-ID: <gZwt2NF48zGs3H35ZN94qQ0_39I46CrmkioGw9VFa8E=.ab2d03a8-a01f-40b1-bcc6-f024d3241b10@github.com>

> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
> 
> Hence we are adding a system test now.
> 
> Test is written as 
> 1. Load html content in web view.
> 2. pick the color of mouse pointer.
> 3. Perform double click.
> 4. pick the color again.
>> expected bahaviour: colour picked in step 2 and 4 should not match.
> 
> Verification:
> The test passes with latest webkit source
> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.

Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:

  Addressed Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1719/files
  - new: https://git.openjdk.org/jfx/pull/1719/files/8f0a0bdd..830c6d29

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=00-01

  Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1719/head:pull/1719

PR: https://git.openjdk.org/jfx/pull/1719

From duke at openjdk.org  Mon Mar  3 11:29:33 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 3 Mar 2025 11:29:33 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
Message-ID: <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>

> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
> 
> Hence we are adding a system test now.
> 
> Test is written as 
> 1. Load html content in web view.
> 2. pick the color of mouse pointer.
> 3. Perform double click.
> 4. pick the color again.
>> expected bahaviour: colour picked in step 2 and 4 should not match.
> 
> Verification:
> The test passes with latest webkit source
> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.

Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:

 - Addressed Review comments
 - Addressed Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1719/files
  - new: https://git.openjdk.org/jfx/pull/1719/files/830c6d29..b4836243

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=01-02

  Stats: 35 lines in 1 file changed: 2 ins; 25 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1719/head:pull/1719

PR: https://git.openjdk.org/jfx/pull/1719

From duke at openjdk.org  Mon Mar  3 12:10:47 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Mon, 3 Mar 2025 12:10:47 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <8PtPXD8hTVpzl0XixxqhNiN1rDeyWp9hBvbcikFd2bI=.ec693954-976e-47dd-8256-37c2bafa6886@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <8PtPXD8hTVpzl0XixxqhNiN1rDeyWp9hBvbcikFd2bI=.ec693954-976e-47dd-8256-37c2bafa6886@github.com>
Message-ID: <7_S-ofCWiMT4jMMpBgmtfLcRazXxFLbi6B4hLkEUQx0=.93ee212e-b612-4d5b-8de1-29925c6207c2@github.com>

On Fri, 28 Feb 2025 21:37:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Addressed Review comments
>>  - Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 45:
> 
>> 43: import test.util.Util;
>> 44: 
>> 45: public class TextSelectionTest {
> 
> I wonder if we could extend RobotTestBase base class to simplify the code?

Done.

> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 47:
> 
>> 45: public class TextSelectionTest {
>> 46: 
>> 47:     private static final String html = "<html>" +
> 
> we could use new java text block here
> 
> 
> private static final String html =
>     """
>     <html>
>     <head></head>
>     <body>&nbsp&nbsp&nbsp&nbsp some text</body>
>     </html>
>     """;

Done.

> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 97:
> 
>> 95: 
>> 96:         int x = (int)(scene.getWindow().getX() + scene.getX() + 22);
>> 97:         int y = (int)(scene.getWindow().getY() + scene.getY() + 15);
> 
> can these offsets (22, 15) be measured instead of hard-coded?

We are not getting the text area from web view. This point is used to simulate the mouse click.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1977381755
PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1977380257
PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1977379556

From angorya at openjdk.org  Mon Mar  3 16:30:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 16:30:06 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
Message-ID: <OrvkcLFR_y2k1CrGmkUFd4Zmvukdvv4aAzXLcTjyGqc=.72924bf0-9509-4f6c-bd6f-4ff5c2bb7173@github.com>

On Wed, 26 Feb 2025 11:30:50 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Create implementation for Slider and Stepper accessibility protocols.
>> Fix mapping.
>> Fix performAction parameter type in declaration.
>
> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Add accessibilityTitleUIElement function to the base class.
>  - Merge branch 'master' into JDK-8313556
>  - Merge pull request #13 from openjdk/master
>    
>    Merge
>  - Merge pull request #12 from openjdk/master
>    
>    Merge
>  - Merge pull request #11 from openjdk/master
>    
>    Merge
>  - Merge pull request #10 from openjdk/master
>    
>    Merge
>  - Adding accessibilityMinValue and accessibilityMaxValue
>  - Merge remote-tracking branch 'origin/master' into JDK-8313556
>  - Merge pull request #7 from openjdk/master
>    
>    Merge
>  - - Added accessibilityTitle method
>    - Removed some debug output generation
>  - ... and 4 more: https://git.openjdk.org/jfx/compare/7a7854c9...09f68099

Is this PR related to  https://git.openjdk.org/jdk/pull/23841 in any way?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2694930458

From kizune at openjdk.org  Mon Mar  3 16:58:17 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 16:58:17 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <65HCZyfzuXcId6WPcOPeewV0i_t1mF5GYbWOCqyE3Tw=.f1d028ce-6766-48e8-a6e0-b0aa63050250@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
 <65HCZyfzuXcId6WPcOPeewV0i_t1mF5GYbWOCqyE3Tw=.f1d028ce-6766-48e8-a6e0-b0aa63050250@github.com>
Message-ID: <YDeEiTHr8gNd4hEu9Yt4wIKClv72ZMuVf4qjWiIM3Tc=.84706803-c632-41a3-9895-cb03e226bc6e@github.com>

On Fri, 28 Feb 2025 11:43:39 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Add accessibilityTitleUIElement function to the base class.
>>  - Merge branch 'master' into JDK-8313556
>>  - Merge pull request #13 from openjdk/master
>>    
>>    Merge
>>  - Merge pull request #12 from openjdk/master
>>    
>>    Merge
>>  - Merge pull request #11 from openjdk/master
>>    
>>    Merge
>>  - Merge pull request #10 from openjdk/master
>>    
>>    Merge
>>  - Adding accessibilityMinValue and accessibilityMaxValue
>>  - Merge remote-tracking branch 'origin/master' into JDK-8313556
>>  - Merge pull request #7 from openjdk/master
>>    
>>    Merge
>>  - - Added accessibilityTitle method
>>    - Removed some debug output generation
>>  - ... and 4 more: https://git.openjdk.org/jfx/compare/7a7854c9...09f68099
>
> modules/javafx.graphics/src/main/native-glass/mac/a11y/AccessibleBase.m line 165:
> 
>> 163:     GLASS_CHECK_EXCEPTION(env);
>> 164:     return variantToID(env, jresult);
>> 165: }
> 
> This method is same as `accessibilityLabel`. Should we change implementation to call one method from the other ?

Makes sense.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1226#discussion_r1977853670

From kizune at openjdk.org  Mon Mar  3 16:58:11 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Mon, 3 Mar 2025 16:58:11 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <R-_y7qMgzUkG615LV9B8W8YHWc1RxxjWf2La1mNel4E=.a65ea895-d122-41f4-bb37-5aa504317479@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
 <R-_y7qMgzUkG615LV9B8W8YHWc1RxxjWf2La1mNel4E=.a65ea895-d122-41f4-bb37-5aa504317479@github.com>
Message-ID: <6SgIXUhWU5LrOJdw9_zpIdV4nojDvqX_oxXmks_7LvI=.70e6b188-858c-4909-aa0f-674d1754ac5e@github.com>

On Fri, 28 Feb 2025 23:41:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> With Slider, it announces the current value as "percent" (of the working envelope?), even though the min/max can be arbitrary. Is this intentional?
> 
> Also, for Spinner, it says "Stepper", is this expected?
> 
> macOS 15.3.1 M1

I need to check that.

> Is this PR related to https://git.openjdk.org/jdk/pull/23841 in any way?

Not directly. The event delivery in AWT/Swing and in JavaFX works quite differently so i will check if the new implementation here is affected by the same problem - but i doubt so.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2695003341
PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2695006784

From jhendrikx at openjdk.org  Mon Mar  3 19:15:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 19:15:15 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v5]
In-Reply-To: <bnnntl1yRHwgN9ycirb2ExXwGXCGCY1yWT5NXjnY9tk=.e70cc523-15ab-4062-ba6f-aec9092574de@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <a8QcT2WNcZbz4lLGkcAufiuuYRtV0hKlq9oTYLfhb3Y=.7213b233-b77b-4864-ad32-8d4021e886f6@github.com>
 <bnnntl1yRHwgN9ycirb2ExXwGXCGCY1yWT5NXjnY9tk=.e70cc523-15ab-4062-ba6f-aec9092574de@github.com>
Message-ID: <xP2rrGXZxya9YhggUj_Uten4xSJoceYacJ8CWBHPuOg=.2f6185f8-1b71-4c8d-8c94-844805f824a1@github.com>

On Thu, 20 Feb 2025 03:08:33 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix fix for regression :)
>
> I've thought about it and I would like to hear what others think. I have a behavior in mind that I find intuitive, but it doesn't mean others will. It actually includes throwing SOEs when listeners fight to set a value, I don't think it's an incorrect behavior (user's fault). Using your Z, A to D order, where A and C change values,
> 
> Z 0->1
> A 0->1; set 2
>   Z 1->2;
>   A 1->2; no change
>   B 0->2
>   C 0->2; sets 3
>     Z 2->3
>     A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's say A wants value>=2 and not ==2
>     B 2->3
>     C 2->3; no change
>     D 0->3
>   D ignores set->2 event since it got a more updated value (tracked by the progress value?)
> B, C, D ignore set->1 event since they got a more updated value
> 
> This should still preserve the 3 rules you outlined. Each listener reacts immediately (depth first) and always in order. This causes the last listener to act to be the one that determines the final value, and not the first one. The ignored values end up being the later ones.
> This, of course, doesn't deal with removal/addition of listeners. I think that removal should work immediately as it does now, but still allow the immediate notifications prior. About addition I'm still not sure.
> 
> ---
> 
> I want to take a boarder view again for a moment. I went back to https://github.com/openjdk/jfx/pull/837 to make sure I didn't drift off course. The fixes for change listeners only pertain to nested events, right? Without nested events, even the current `ExpressionListener` works correctly, yes?

@nlisker Is there anything that still needs to be discussed at this point?  I think that you found some interesting edge cases, but as most involved registering and removing listener on the same property on which you already have a listener, I think that those are more hypothetical than cases we need to document or remain compatible with.

I think that this implementation operates well within the current specification (ie. it could be integrated without any documentation clarifications), but I'm open to specifying some behavior (as provided by JavaFX) explicitly so applications may rely on it more (if they aren't already).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2695313605

From angorya at openjdk.org  Mon Mar  3 20:01:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 20:01:04 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <R_Pg29R7l_23GqZydRPBPF1SIO6X-_N54n3-5Vu4GE4=.b342988c-85b5-498a-81da-a83608e8e782@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <CvkS7J6L4lVBchrmVUaaf7we91sQl8GPv6x4m8FgbdA=.aaceadcb-5741-4108-9b40-2b118f243c5f@github.com>
 <R_Pg29R7l_23GqZydRPBPF1SIO6X-_N54n3-5Vu4GE4=.b342988c-85b5-498a-81da-a83608e8e782@github.com>
Message-ID: <56Vo0Bid02n4vRGJDPwRGVFODUcZZpOrfsUQ0PIyxbM=.f83ee79c-7de0-45ae-9034-15a3e6715018@github.com>

On Fri, 28 Feb 2025 18:34:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 561:
>> 
>>> 559:                 accessibilityActive = winProp; // keep the reference so it won't get gc
>>> 560: 
>>> 561:                 // lambda cannot be used in place of a ChangeListener in removeListener()
>> 
>> Why not use a Subscription then? It seems tailor-made for what you are trying to do.
>
> I don't know how to use Subscription in this case.  
> This does not work:
> 
> 
>                 ObservableValue<Window> winProp = sceneProperty().flatMap(Scene::windowProperty);
>                 accessibilityActive = winProp; // keep the reference so it won't get gc
>                 Subscription sub = winProp.subscribe((win) -> {
>                     if (win != null) {
>                         if (accessibilityActive == winProp) {
>                             accessibilityActive = null;
>                         }
>                         if (isAccessibilityActive()) {
>                             handleAccessibilityActive(true);
>                         }
>                         //winProp.removeListener(this);
>                         sub.unsubscribe(); <-- COMPILE ERROR
>                     }
>                 });

@hjohn could you help here please?  How could we use Subscription in a situation when it has to be unsubscribed from within the lambda?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978113628

From jhendrikx at openjdk.org  Mon Mar  3 20:38:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 20:38:03 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <56Vo0Bid02n4vRGJDPwRGVFODUcZZpOrfsUQ0PIyxbM=.f83ee79c-7de0-45ae-9034-15a3e6715018@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <CvkS7J6L4lVBchrmVUaaf7we91sQl8GPv6x4m8FgbdA=.aaceadcb-5741-4108-9b40-2b118f243c5f@github.com>
 <R_Pg29R7l_23GqZydRPBPF1SIO6X-_N54n3-5Vu4GE4=.b342988c-85b5-498a-81da-a83608e8e782@github.com>
 <56Vo0Bid02n4vRGJDPwRGVFODUcZZpOrfsUQ0PIyxbM=.f83ee79c-7de0-45ae-9034-15a3e6715018@github.com>
Message-ID: <yRjD2k9enGxuYBOuf58eWS5k5O9fFGIUrV35Qi2j3AA=.e7c30a94-2c04-4a70-925f-63cce07484f9@github.com>

On Mon, 3 Mar 2025 19:58:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I don't know how to use Subscription in this case.  
>> This does not work:
>> 
>> 
>>                 ObservableValue<Window> winProp = sceneProperty().flatMap(Scene::windowProperty);
>>                 accessibilityActive = winProp; // keep the reference so it won't get gc
>>                 Subscription sub = winProp.subscribe((win) -> {
>>                     if (win != null) {
>>                         if (accessibilityActive == winProp) {
>>                             accessibilityActive = null;
>>                         }
>>                         if (isAccessibilityActive()) {
>>                             handleAccessibilityActive(true);
>>                         }
>>                         //winProp.removeListener(this);
>>                         sub.unsubscribe(); <-- COMPILE ERROR
>>                     }
>>                 });
>
> @hjohn could you help here please?  How could we use Subscription in a situation when it has to be unsubscribed from within the lambda?

I haven't been tracking these fixes for allowing initialization in background threads, but it seems to me that basically anything should be allowed as long as you're not part of a visible scene graph -- and I think there's also no expectation that all functionality of a control "works" as long as it is not yet part of such a graph (ie. the listeners are only needed once it is part of a scene graph).

If you make listeners conditional on being part of a scene graph, then I think you can handle these with a single code path.  Such a condition would be:

    ObservableValue<Boolean> partOfSceneGraph = node.sceneProperty()
      .flatMap(Scene::windowProperty)
      .flatMap(Window::showingProperty)
      .orElse(false);
      
You can then safely install any listeners directly, regardless if they're on a background thread or not:

    someProperty().when(partOfSceneGraph).subscribe( ... );

Or:

    someProperty().when(partOfSceneGraph).addListener( ... );

On a background thread, `partOfSceneGraph` will be `false`, and no listener gets installed (yet).  As soon as it becomes `true` all listeners with that same condition become active.  It becomes `true` automatically when the node has a scene belonging to a window that is visible.  Vice versa, if it ever becomes `false` again, (which it may when the Node is removed or replaced) all listeners using this condition are removed again.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978157784

From angorya at openjdk.org  Mon Mar  3 20:46:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 20:46:58 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <yRjD2k9enGxuYBOuf58eWS5k5O9fFGIUrV35Qi2j3AA=.e7c30a94-2c04-4a70-925f-63cce07484f9@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <CvkS7J6L4lVBchrmVUaaf7we91sQl8GPv6x4m8FgbdA=.aaceadcb-5741-4108-9b40-2b118f243c5f@github.com>
 <R_Pg29R7l_23GqZydRPBPF1SIO6X-_N54n3-5Vu4GE4=.b342988c-85b5-498a-81da-a83608e8e782@github.com>
 <56Vo0Bid02n4vRGJDPwRGVFODUcZZpOrfsUQ0PIyxbM=.f83ee79c-7de0-45ae-9034-15a3e6715018@github.com>
 <yRjD2k9enGxuYBOuf58eWS5k5O9fFGIUrV35Qi2j3AA=.e7c30a94-2c04-4a70-925f-63cce07484f9@github.com>
Message-ID: <HWSLlIRBVMUnl_2WI1tDvk60ynEaz0ceY70Z_mZ9r0E=.47315aae-1a43-46d6-883c-b5af0148d375@github.com>

On Mon, 3 Mar 2025 20:35:21 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> @hjohn could you help here please?  How could we use Subscription in a situation when it has to be unsubscribed from within the lambda?
>
> I haven't been tracking these fixes for allowing initialization in background threads, but it seems to me that basically anything should be allowed as long as you're not part of a visible scene graph -- and I think there's also no expectation that all functionality of a control "works" as long as it is not yet part of such a graph (ie. the listeners are only needed once it is part of a scene graph).
> 
> If you make listeners conditional on being part of a scene graph, then I think you can handle these with a single code path.  Such a condition would be:
> 
>     ObservableValue<Boolean> partOfSceneGraph = node.sceneProperty()
>       .flatMap(Scene::windowProperty)
>       .flatMap(Window::showingProperty)
>       .orElse(false);
>       
> You can then safely install any listeners directly, regardless if they're on a background thread or not:
> 
>     someProperty().when(partOfSceneGraph).subscribe( ... );
> 
> Or:
> 
>     someProperty().when(partOfSceneGraph).addListener( ... );
> 
> On a background thread, `partOfSceneGraph` will be `false`, and no listener gets installed (yet).  As soon as it becomes `true` all listeners with that same condition become active.  It becomes `true` automatically when the node has a scene belonging to a window that is visible.  Vice versa, if it ever becomes `false` again, (which it may when the Node is removed or replaced) all listeners using this condition are removed again.

Thank you!

This is not what I asked though: my question was about using `Subscription` in one-off case, and more specifically, about whether it is even possible to unsubscribe from within the lambda.

What you are proposing is a slightly more involved change: for example, registering and unregistering listeners each time might introduce other issues (especially since we have no way to prioritize listeners/handlers).  It also complicates the management of skin (as skins can be added/removed), something I would rather avoid.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978169002

From jhendrikx at openjdk.org  Mon Mar  3 20:51:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 20:51:00 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <HWSLlIRBVMUnl_2WI1tDvk60ynEaz0ceY70Z_mZ9r0E=.47315aae-1a43-46d6-883c-b5af0148d375@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <CvkS7J6L4lVBchrmVUaaf7we91sQl8GPv6x4m8FgbdA=.aaceadcb-5741-4108-9b40-2b118f243c5f@github.com>
 <R_Pg29R7l_23GqZydRPBPF1SIO6X-_N54n3-5Vu4GE4=.b342988c-85b5-498a-81da-a83608e8e782@github.com>
 <56Vo0Bid02n4vRGJDPwRGVFODUcZZpOrfsUQ0PIyxbM=.f83ee79c-7de0-45ae-9034-15a3e6715018@github.com>
 <yRjD2k9enGxuYBOuf58eWS5k5O9fFGIUrV35Qi2j3AA=.e7c30a94-2c04-4a70-925f-63cce07484f9@github.com>
 <HWSLlIRBVMUnl_2WI1tDvk60ynEaz0ceY70Z_mZ9r0E=.47315aae-1a43-46d6-883c-b5af0148d375@github.com>
Message-ID: <J8aCWFuEnxjNUOoVeb6DO2ns-8RM9rKTHbkHH3QAcnk=.4940c929-d4a2-4b5c-a1de-31af93c0d9cd@github.com>

On Mon, 3 Mar 2025 20:44:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> I haven't been tracking these fixes for allowing initialization in background threads, but it seems to me that basically anything should be allowed as long as you're not part of a visible scene graph -- and I think there's also no expectation that all functionality of a control "works" as long as it is not yet part of such a graph (ie. the listeners are only needed once it is part of a scene graph).
>> 
>> If you make listeners conditional on being part of a scene graph, then I think you can handle these with a single code path.  Such a condition would be:
>> 
>>     ObservableValue<Boolean> partOfSceneGraph = node.sceneProperty()
>>       .flatMap(Scene::windowProperty)
>>       .flatMap(Window::showingProperty)
>>       .orElse(false);
>>       
>>       // The node here is "this", the chart, because as soon as it is part of the scene
>>       // graph, you want the listeners to function.
>>       
>> You can then safely install any listeners directly, regardless if they're on a background thread or not:
>> 
>>     someProperty().when(partOfSceneGraph).subscribe( ... );
>> 
>> Or:
>> 
>>     someProperty().when(partOfSceneGraph).addListener( ... );
>> 
>> Or with any mappings added, you can even pick where you put the `when`:
>> 
>>     someProperty().flatMap(xyz).when(partOfSceneGraph).addListener( ... );
>>     someProperty().when(partOfSceneGraph).flatMap(xyz).addListener( ... );
>> 
>> 
>> On a background thread, `partOfSceneGraph` will be `false`, and no listener gets installed (yet).  As soon as it becomes `true` all listeners with that same condition become active.  It becomes `true` automatically when the node has a scene belonging to a window that is visible.  Vice versa, if it ever becomes `false` again, (which it may when the Node is removed or replaced) all listeners using this condition are removed again.
>
> Thank you!
> 
> This is not what I asked though: my question was about using `Subscription` in one-off case, and more specifically, about whether it is even possible to unsubscribe from within the lambda.
> 
> What you are proposing is a slightly more involved change: for example, registering and unregistering listeners each time might introduce other issues (especially since we have no way to prioritize listeners/handlers).  It also complicates the management of skin (as skins can be added/removed), something I would rather avoid.

As for this current code:

                ObservableValue<Window> winProp = sceneProperty().flatMap(Scene::windowProperty);
                accessibilityActive = winProp; // keep the reference so it won't get gc
                Subscription sub = winProp.subscribe((win) -> {
                    if (win != null) {
                        if (accessibilityActive == winProp) {
                            accessibilityActive = null;
                        }
                        if (isAccessibilityActive()) {
                            handleAccessibilityActive(true);
                        }
                        //winProp.removeListener(this);
                        sub.unsubscribe(); <-- COMPILE ERROR
                    }
                });
                
What you want there is not possible in this way as you can't use `this` in a lambda, nor refer to it via a local.  You can achieve it only if you store the subscription in a field, not in a local.  Assigning the Lambda to a ChangeListener local, and using a ChangeListener may be simpler (unless you go for the `when` solution that may eliminate the need for 2 different code paths).

Note that there is no need to store `winProp`; `flatMap` does not use weak listeners (when in active use), and so as long as `sceneProperty()` exists, the derived property via `flatMap` will also exist, and also its listener.  The way the fluent mapping system works is that listeners are only present when something is actually listening:

    ObservableValue<Window> winProp = sceneProperty().flatMap(Scene::windowProperty);
    // ^^ nobody is listening, so no listeners installed and no hard references; it could GC but
    // it is currently in a local, so it won't
    
    ObservableValue<Window> winProp = sceneProperty().flatMap(Scene::windowProperty);
    winProp.subscribe(v -> { .. });
    // ^^ somebody is listening; all listeners get installed automatically, and now there are
    // hard references.  No risk of GC.
    
You can then write it as a single statement which won't be GC'd as long as the subscription is active:
    
    subscriptionFIeld = sceneProperty()
        .flatMap(Scene::windowProperty);
        .subscribe(v -> { 
            // use subscription field here if you want to unregister the lambda
            // Note: when you do, there will again be no listeners and thus no hard references and
            // thus the intermediate property created by flatMap can now be GC'd :)
        });

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978173310

From kcr at openjdk.org  Mon Mar  3 21:00:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 21:00:00 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v2]
In-Reply-To: <kfrcT_CLIDdiUKeqdGehQGwsVM7yJjIWXtpXrsJ3T5g=.97618161-bc14-43b5-a1f0-b0c9cde20556@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <iEuEoHBByjx_KRSXhtu8l27JmKKdVacAt1rUmghbs08=.c1d88e17-7947-43f1-91af-7dd068ee32fd@github.com>
 <m46vieM-1GJQm0MQYN7xdKwkqIe-Ce5sOjLxqSkKUH4=.3281582a-9e26-46c4-bcb9-744981d680d2@github.com>
 <lCvVSZZxcYoRS63ahknQApV633Gs1LZopyWmx_Kfj14=.6fa50c32-3df6-4dd5-b8e0-307b0294e804@github.com>
 <dcSBtEMWBX5TkzMW9bmOxNT3poJlyvz-rZ3BMaNBBQ4=.b8547998-a733-4424-964b-54bfbb07453b@github.com>
 <O17jC9KvouowBiKFW6vhCCj4IL1Bx0cmQ3XPNobF1SI=.24fd812e-c0c5-447a-ba09-01743ac3d2aa@github.com>
 <kfrcT_CLIDdiUKeqdGehQGwsVM7yJjIWXtpXrsJ3T5g=.97618161-bc14-43b5-a1f0-b0c9cde20556@github.com>
Message-ID: <73Iu5DHdJurziE5J2wxb7JfXh9WVg6p9qbWaGDBb4BI=.5ecb3821-2f6c-4b95-8855-beb33d8ef8cc@github.com>

On Fri, 28 Feb 2025 23:08:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I think the main concern with the reformatting/tangentially related changes coming from the maintainers is the general pain associated with conflicts created when merging and backporting.

It's not just this, it's also about avoiding changes in parts of the code you aren't touching. When you do this, reviewers have to look at a hole bunch of changes that aren't related to the fix.

> In this case, I think we might be ok, specifically in the tests. I would rather see the cleaner and more maintainable code, even at the small additional expense. Up to you.

If a fix touches only one method of a file with many methods, I very much do not want to see the entire file reformatted as part of that fix. So I recommend to either reformat the one method or leave it alone.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r1978183387

From jhendrikx at openjdk.org  Mon Mar  3 21:05:05 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 21:05:05 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
Message-ID: <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>

On Tue, 25 Feb 2025 22:33:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - enabled pie chart test
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - cleanup
>  - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0

modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 546:

> 544:             symbol.setAccessibleRole(AccessibleRole.TEXT);
> 545:             symbol.setAccessibleRoleDescription("Point");
> 546:             symbol.setFocusTraversable(isAccessibilityActive());

So, if I understand correctly, we can't directly do this `bind`:

    symbol.focusTraversableProperty().bind(Platform.accessibilityActiveProperty())
    
Because on a background thread there may not yet be an initialized `Platform`?  Or perhaps, `Platform` would need to initialize and we don't want to do that yet on a background thread?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978188666

From kcr at openjdk.org  Mon Mar  3 21:07:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 21:07:04 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <O74JcJXzQb3k9GGUbu14PHPErKD7sNone0GjxRnfBxg=.0b47fe6d-beae-4168-9cc9-e3cea5714bb4@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <O74JcJXzQb3k9GGUbu14PHPErKD7sNone0GjxRnfBxg=.0b47fe6d-beae-4168-9cc9-e3cea5714bb4@github.com>
Message-ID: <TyfkbwPmSHWG3woXXGHG2Ox6hZIKMJ0DExwNiafiTkk=.231f88c5-fc3a-4413-97ed-107becbb7d31@github.com>

On Sat, 1 Mar 2025 10:30:49 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md
>
> Marked as reviewed by jhendrikx (Reviewer).

@hjohn Thanks for the review and the suggestions. I'll apply them in a day or two when I get back to this.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1712#issuecomment-2695531912

From kcr at openjdk.org  Mon Mar  3 21:13:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 21:13:02 GMT
Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <53gwa9ouTh8bGYWLsXHODmhDW7e13Pbk3ycOAaziKpw=.1762114c-75b2-42bc-b28e-452f72255707@github.com>
References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com>
 <53gwa9ouTh8bGYWLsXHODmhDW7e13Pbk3ycOAaziKpw=.1762114c-75b2-42bc-b28e-452f72255707@github.com>
Message-ID: <6mrGOPqcOwmUldRXSeoQBUKl1UTQocjBOS17Qb_eq18=.c5cbd34a-9839-4bb2-8164-0b57ff55c414@github.com>

On Sat, 1 Mar 2025 04:02:55 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

>> Backport the JavaFX 23 release notes to the `jfx23` branch. Note that we will _not_ trigger a respin of JavaFX 23 as a result of this.
>
> doc-files/release-notes-23.md line 11:
> 
>> 9: ## Important Changes
>> 10: 
>> 11: ### JavaFX 23 Requires JDK 21 or Later
> 
> why are `Requires` and `Later` capitalised?
> 
> I went back and it was also the case with [JFX 23 release notes](https://github.com/openjdk/jfx/pull/1563/files#diff-2d16210695314e7aef40df186b6428372f477736598ee49496f5340159d72fcbR11). Just curious is there a defined casing style that we follow for release notes?

This is the PR for the JavaFX 23 release notes. Did you mean to ask your question in PR #1712 , which is under review for the JavaFX 24 release notes? In any case, I'll answer your question here.

> why are `Requires` and `Later` capitalised?
> 
> I went back and it was also the case with [JFX 23 release notes](https://github.com/openjdk/jfx/pull/1563/files#diff-2d16210695314e7aef40df186b6428372f477736598ee49496f5340159d72fcbR11). Just curious is there a defined casing style that we follow for release notes?

See [this section of the OpenJDK Developers Guide](https://openjdk.org/guide/#general-conventions-for-release-notes).


The Summary should be in title case instead of sentence case.

    Example: Decode Error with Tomcat Version 7.x

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1563#discussion_r1978198639

From angorya at openjdk.org  Mon Mar  3 21:15:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 21:15:08 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
Message-ID: <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>

On Mon, 3 Mar 2025 21:01:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - enabled pie chart test
>>  - Merge branch 'master' into 8349091.charts.thread.safety
>>  - Merge branch 'master' into 8349091.charts.thread.safety
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - cleanup
>>  - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0
>
> modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 546:
> 
>> 544:             symbol.setAccessibleRole(AccessibleRole.TEXT);
>> 545:             symbol.setAccessibleRoleDescription("Point");
>> 546:             symbol.setFocusTraversable(isAccessibilityActive());
> 
> So, if I understand correctly, we can't directly do this `bind`:
> 
>     symbol.focusTraversableProperty().bind(Platform.accessibilityActiveProperty())
>     
> Because on a background thread there may not yet be an initialized `Platform`?  Or perhaps, `Platform` would need to initialize and we don't want to do that yet on a background thread?

The reason we `should not` be binding in this PR is because in part it's **bad design(tm)**: we are creating a zillion of listeners (one per plot data point); a better solution would be to create one listener and use (already existing series) to toggle the data points.

The other reason is https://bugs.openjdk.org/browse/JDK-8351067 - the `Platform::accessibilityActive` property getter is not thread safe, but even if was, registering a listener with it may cause the change to come in **before** the node becomes a part of the scene graph, leading to unsynchronized multi-threaded access.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978198906

From duke at openjdk.org  Mon Mar  3 21:16:04 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Mon, 3 Mar 2025 21:16:04 GMT
Subject: [jfx23] RFR: 8339247: Create release notes for JavaFX 23
In-Reply-To: <6mrGOPqcOwmUldRXSeoQBUKl1UTQocjBOS17Qb_eq18=.c5cbd34a-9839-4bb2-8164-0b57ff55c414@github.com>
References: <24HJ4HeJyRz9sbE0xLTXIFsCk2zqfQV2jRwl3_mD08c=.805d987b-e724-465b-8983-edc037cce29b@github.com>
 <53gwa9ouTh8bGYWLsXHODmhDW7e13Pbk3ycOAaziKpw=.1762114c-75b2-42bc-b28e-452f72255707@github.com>
 <6mrGOPqcOwmUldRXSeoQBUKl1UTQocjBOS17Qb_eq18=.c5cbd34a-9839-4bb2-8164-0b57ff55c414@github.com>
Message-ID: <yu-hyej4WZ0T5aSQ-5v2H196evy_toqI4UU5zhsUfRs=.b02ce06d-9555-4f7e-86d2-986ea7666622@github.com>

On Mon, 3 Mar 2025 21:10:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This is the PR for the JavaFX 23 release notes

My bad.

> See [this section of the OpenJDK Developers Guide](https://openjdk.org/guide/#general-conventions-for-release-notes).

Thank you for the link.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1563#discussion_r1978201741

From jhendrikx at openjdk.org  Mon Mar  3 21:26:03 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 21:26:03 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
Message-ID: <QdfVbBxpTwaU51ba1OLTeL5aTZah0q74RJw1FpK_ROw=.3c84160e-c4b1-4897-8928-2b126a83cfce@github.com>

On Tue, 25 Feb 2025 22:33:40 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - enabled pie chart test
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - whitespace
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - cleanup
>  - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0

modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 550:

> 548:                     handleAccessibilityActive(on);
> 549:                 });
> 550:                 return active.get();

I'm confused as to what is happening here.  A boolean property `active` is created, which is bound to `Platform.accessibilityActiveProperty` (this creates a listener on `accessibilityActiveProperty`). We add then another listener on `active`.  

What confuses me is what this is supposed to achieve, and also why we're initialising the property, but then bind it anyway... `active = new SimpleBooleanProperty(aa)` and later `active.bind` means that the variable `aa` is completely unnecessary as the `bind` will do this `get` for you.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978258927

From jhendrikx at openjdk.org  Mon Mar  3 21:32:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 21:32:58 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
Message-ID: <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>

On Mon, 3 Mar 2025 21:10:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/chart/AreaChart.java line 546:
>> 
>>> 544:             symbol.setAccessibleRole(AccessibleRole.TEXT);
>>> 545:             symbol.setAccessibleRoleDescription("Point");
>>> 546:             symbol.setFocusTraversable(isAccessibilityActive());
>> 
>> So, if I understand correctly, we can't directly do this `bind`:
>> 
>>     symbol.focusTraversableProperty().bind(Platform.accessibilityActiveProperty())
>>     
>> Because on a background thread there may not yet be an initialized `Platform`?  Or perhaps, `Platform` would need to initialize and we don't want to do that yet on a background thread?
>
> The reason we `should not` be binding in this PR is because in part it's **bad design(tm)**: we are creating a zillion of listeners (one per plot data point); a better solution would be to create one listener and use (already existing series) to toggle the data points.
> 
> The other reason is https://bugs.openjdk.org/browse/JDK-8351067 - the `Platform::accessibilityActive` property getter is not thread safe, but even if was, registering a listener with it may cause the change to come in **before** the node becomes a part of the scene graph, leading to unsynchronized multi-threaded access.

Was this solution considered:

    ObservableValue<Boolean> partOfSceneGraph = this.sceneProperty()
      .flatMap(Scene::windowProperty)
      .flatMap(Window::showingProperty)
      .orElse(false);
      
    symbol.focusTraversableProperty()
        .bind(Platform.accessibilityActiveProperty().when(partOfSceneGraph));
        
What the above code does is create a binding on the `when` statement (a listener is added on the `when` result).  However, the `when` property will not add a listener on `Platform.accessibilityActiveProperty()` until `partOfSceneGraph` is `true`.  As soon as it does though, a listener is installed on  `Platform.accessibilityActiveProperty()` and its latest value is set to `focusTraversableProperty` via the bind.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978264839

From jhendrikx at openjdk.org  Mon Mar  3 21:32:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 21:32:58 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
Message-ID: <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>

On Mon, 3 Mar 2025 21:28:13 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> The reason we `should not` be binding in this PR is because in part it's **bad design(tm)**: we are creating a zillion of listeners (one per plot data point); a better solution would be to create one listener and use (already existing series) to toggle the data points.
>> 
>> The other reason is https://bugs.openjdk.org/browse/JDK-8351067 - the `Platform::accessibilityActive` property getter is not thread safe, but even if was, registering a listener with it may cause the change to come in **before** the node becomes a part of the scene graph, leading to unsynchronized multi-threaded access.
>
> Was this solution considered:
> 
>     ObservableValue<Boolean> partOfSceneGraph = this.sceneProperty()
>       .flatMap(Scene::windowProperty)
>       .flatMap(Window::showingProperty)
>       .orElse(false);
>       
>     symbol.focusTraversableProperty()
>         .bind(Platform.accessibilityActiveProperty().when(partOfSceneGraph));
>         
> What the above code does is create a binding on the `when` statement (a listener is added on the `when` result).  However, the `when` property will not add a listener on `Platform.accessibilityActiveProperty()` until `partOfSceneGraph` is `true`.  As soon as it does though, a listener is installed on  `Platform.accessibilityActiveProperty()` and its latest value is set to `focusTraversableProperty` via the bind.

The above does require though that `Platform.accessibilityActiveProperty()` is properly synchronized.  I think it may be a good idea to fix that first.  Perhaps all platform provided properties (if there are more) should ensure they're only initialized once.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978267599

From jhendrikx at openjdk.org  Mon Mar  3 21:35:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 3 Mar 2025 21:35:59 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <89rYaYvaFJzYlJrJtcExcIEQ6GDHYMC8O0XaWJtymSM=.929de5b1-7806-4c6b-9934-d8fa754c373e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <89rYaYvaFJzYlJrJtcExcIEQ6GDHYMC8O0XaWJtymSM=.929de5b1-7806-4c6b-9934-d8fa754c373e@github.com>
Message-ID: <UhVuXM5Yk1f5uk6kSc8QsVrdSUqXWEZCLwtziJ7Ldp4=.f2b0f577-90c0-431d-b24a-1fe405f22523@github.com>

On Tue, 18 Feb 2025 11:13:14 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes
>
> @mstr2 / Dirk Lemmermann : This is a proof of concept PR for parent provided properties.  I've adapted HBox / VBox only in this PR, and I probably need to update the CSS documentation still.  I've opted to leave out the static HBox / VBox method to get these as a property (ie. `hgrowProperty`) although a property is used internally and so it could be exposed fairly easily later.  My plan is:
> 
> - Get some early feedback on the implementation, naming and the new API method in Styleable
> - Decide the scope of this PR; I'd be in favor to get the core code in, then add more support later to ease reviews
>    - Include new static property methods as well?
>    - Include GridPane as well?
>    - Any other controls?
> - Add some specific unit tests for this new feature
> - Update CSS docs
> - Ready for review
> - Integrate

> Only the author (@hjohn) is allowed to issue the reviewer command.

That's weird isn't it?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2695603370

From angorya at openjdk.org  Mon Mar  3 21:39:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 21:39:02 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <QdfVbBxpTwaU51ba1OLTeL5aTZah0q74RJw1FpK_ROw=.3c84160e-c4b1-4897-8928-2b126a83cfce@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <QdfVbBxpTwaU51ba1OLTeL5aTZah0q74RJw1FpK_ROw=.3c84160e-c4b1-4897-8928-2b126a83cfce@github.com>
Message-ID: <nVeqSS1ZsFQSVZCr5O3l3RED-h2LCMJKE7SETg41wlo=.c1c1a7d1-6ac1-486e-b29b-12e02b8ab63e@github.com>

On Mon, 3 Mar 2025 21:23:47 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - enabled pie chart test
>>  - Merge branch 'master' into 8349091.charts.thread.safety
>>  - Merge branch 'master' into 8349091.charts.thread.safety
>>  - whitespace
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - cleanup
>>  - ... and 15 more: https://git.openjdk.org/jfx/compare/7a7854c9...4288d1d0
>
> modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 550:
> 
>> 548:                     handleAccessibilityActive(on);
>> 549:                 });
>> 550:                 return active.get();
> 
> I'm confused as to what is happening here.  A boolean property `active` is created, which is bound to `Platform.accessibilityActiveProperty` (this creates a listener on `accessibilityActiveProperty`). We add then another listener on `active`.  
> 
> What confuses me is what this is supposed to achieve, and also why we're initialising the property, but then bind it anyway... `active = new SimpleBooleanProperty(aa)` and later `active.bind` means that the variable `aa` is completely unnecessary as the `bind` will do this `get` for you.

aa is unnecessary, you are right, bind() will set the value.

the property is created as a way to signal any subsequent calls that no more work is needed.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978273865

From angorya at openjdk.org  Mon Mar  3 21:45:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 21:45:02 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
Message-ID: <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>

On Mon, 3 Mar 2025 21:30:42 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Was this solution considered:
>> 
>>     ObservableValue<Boolean> partOfSceneGraph = this.sceneProperty()
>>       .flatMap(Scene::windowProperty)
>>       .flatMap(Window::showingProperty)
>>       .orElse(false);
>>       
>>     symbol.focusTraversableProperty()
>>         .bind(Platform.accessibilityActiveProperty().when(partOfSceneGraph));
>>         
>> What the above code does is create a binding on the `when` statement (a listener is added on the `when` result).  However, the `when` property will not add a listener on `Platform.accessibilityActiveProperty()` until `partOfSceneGraph` is `true`.  As soon as it does though, a listener is installed on  `Platform.accessibilityActiveProperty()` and its latest value is set to `focusTraversableProperty` via the bind.
>
> The above does require though that `Platform.accessibilityActiveProperty()` is properly synchronized.  I think it may be a good idea to fix that first.  Perhaps all platform provided properties (if there are more) should ensure they're only initialized once.

unrelated, but I would rather disallow background access to any platform properties.

_per the earlier email_, this might (read: will) create concurrent access when the node is not yet attached to the scene graph:


background thread                   fx app thread
1. start creating the node
2. add listener to platform prop
3. keep initializing the node        <-- platform property change notification
4. some more code


step 3 is when concurrent access occurs.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1978282003

From angorya at openjdk.org  Mon Mar  3 21:52:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 3 Mar 2025 21:52:55 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v7]
In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
Message-ID: <wuhcFRWndKUhOydpN26w4A31wZZ8vrt96w5WifOMkFA=.2964883d-cbd2-4c2f-95d7-6c30fdca4558@github.com>

> Root Cause:
> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
> 
> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
> 
> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
> 
> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
> 
> With this change, it is safe to create and populate charts with data in a background thread.
> 
> ---
> 
> ## NOTES
> 
> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
> 
> ## Note to the Reviewers
> 
> To avoid merge conflicts, the preferred order of integrations:
> 
> #1697 
> #1713 
> #1717

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - unnecessary
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - enabled pie chart test
 - Merge branch 'master' into 8349091.charts.thread.safety
 - Merge branch 'master' into 8349091.charts.thread.safety
 - whitespace
 - ... and 17 more: https://git.openjdk.org/jfx/compare/f3ba4485...d212ffd6

-------------

Changes: https://git.openjdk.org/jfx/pull/1697/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=06
  Stats: 323 lines in 11 files changed: 183 ins; 101 del; 39 mod
  Patch: https://git.openjdk.org/jfx/pull/1697.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697

PR: https://git.openjdk.org/jfx/pull/1697

From kcr at openjdk.org  Mon Mar  3 22:52:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 3 Mar 2025 22:52:07 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <GkGB1ucou1zWxMFLTBpYn6D9a_B8seiiesfARTZeB6k=.7b20c17a-e090-441d-ad55-5391577c73ca@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

Well, oops. 

> > Only the author (@hjohn) is allowed to issue the reviewer command.
> 
> That's weird isn't it?

No, it was my mistake. There are two different Skara commands with two different meanings and very similar spelling:

* `/reviewers` -- set the minimum number of reviewers needed to approve
* `/reviewer` -- credit extra reviewers who didn't "review" in the GitHub sense, but whom you want to credit in the meta-data (they don't count towards the minimum number of reviewers)

I meant the first one. I accidentally typed the second.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2695744055

From jvos at openjdk.org  Tue Mar  4 10:27:49 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 10:27:49 GMT
Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10
Message-ID: <1Cyos9KIz4MyGuP-XAJleBGKMjUSkz8U07bHduGCk_k=.ae309274-7f2d-4409-82a3-aa902626c6b7@github.com>

Hi all,

This pull request contains a backport of commit 22035dec from the openjdk/jfx repository.

The commit being backported was authored by Alexander Matveev on 14 Jan 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 22035dec470756e03d254aa12c088876ae20497d

Changes: https://git.openjdk.org/jfx21u/pull/90/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=90&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346228
  Stats: 12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod
  Patch: https://git.openjdk.org/jfx21u/pull/90.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/90/head:pull/90

PR: https://git.openjdk.org/jfx21u/pull/90

From jvos at openjdk.org  Tue Mar  4 10:50:01 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 10:50:01 GMT
Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
References: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
Message-ID: <W5o_-HHTPr8eciKJWLxD6TUZ5EasjzsqephUwX6MpeQ=.0c046412-0c08-429d-aa51-d13539e59dd7@github.com>

On Mon, 24 Feb 2025 16:52:38 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> I'd like to backport the commit 22035dec47 that bring updates to GStreamer and Glib:  
> - 8346228: Update GStreamer to 1.24.10
> - 8346229: Update Glib to 2.82.4
> 
> The original [commit ](https://github.com/openjdk/jfx/commit/22035dec470756e03d254aa12c088876ae20497d) was authored by Alexander Matveev and was reviewed by Joeri Sykora and Kevin Rushforth

These are good to go. Please note that it is more convenient to use the /skara backport jfx21u command as a comment to the original commit. That way, we are guaranteed that the commit is exactly the same as the one in the backport. (I did it manually to check, and all ok here)

-------------

PR Comment: https://git.openjdk.org/jfx21u/pull/89#issuecomment-2697056260

From jvos at openjdk.org  Tue Mar  4 11:13:40 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 11:13:40 GMT
Subject: [jfx21u] RFR: 8323880: Caret rendered at wrong position in case of a
 click event on RTL text
Message-ID: <wNZ0qvp-k363C7LVNlHZTeerMUZTh99nD6UMN2cPZT0=.364a49f6-cd16-4ff3-ab32-3fa331ef713b@github.com>

Hi all,

This pull request contains a backport of commit 1fb56e33 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 16 Feb 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.

Thanks!

-------------

Commit messages:
 - Backport 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3

Changes: https://git.openjdk.org/jfx21u/pull/91/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=91&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323880
  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/91.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/91/head:pull/91

PR: https://git.openjdk.org/jfx21u/pull/91

From jvos at openjdk.org  Tue Mar  4 11:19:10 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 11:19:10 GMT
Subject: [jfx21u] Integrated: 8323880: Caret rendered at wrong position in case
 of a click event on RTL text
In-Reply-To: <wNZ0qvp-k363C7LVNlHZTeerMUZTh99nD6UMN2cPZT0=.364a49f6-cd16-4ff3-ab32-3fa331ef713b@github.com>
References: <wNZ0qvp-k363C7LVNlHZTeerMUZTh99nD6UMN2cPZT0=.364a49f6-cd16-4ff3-ab32-3fa331ef713b@github.com>
Message-ID: <ZcOjd1TwsDxDAJhhV3NOCwJDI5_y5Uiy-aX9tqtgw2Q=.98e4f537-9e92-49c7-813c-0c7799e3a3c5@github.com>

On Tue, 4 Mar 2025 11:08:09 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 1fb56e33 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 16 Feb 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 52658644
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/52658644ff2c85953eec66260d07be0b68c0f487
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8323880: Caret rendered at wrong position in case of a click event on RTL text

Backport-of: 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3

-------------

PR: https://git.openjdk.org/jfx21u/pull/91

From arapte at openjdk.org  Tue Mar  4 12:13:07 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 4 Mar 2025 12:13:07 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v8]
In-Reply-To: <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
Message-ID: <KWc7aspIOO-6Cc51L2WVh1Dzp676H4LWTWX_yulGCWA=.d35feb55-25a6-4eca-bbac-bcf41efc0735@github.com>

On Thu, 30 Jan 2025 23:02:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
>> 
>> Removed earlier manual tester in favor of the monkey tester.
>> 
>> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

LGTM. Tested a few samples of TableView.

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1156#pullrequestreview-2657204035

From kcr at openjdk.org  Tue Mar  4 12:20:05 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 12:20:05 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
Message-ID: <zFAaEFrk80okgpHtzMvfkOFIM3Owax575hU2KJ3qKGg=.3862d038-5cad-4153-8681-1712065a665f@github.com>

On Mon, 3 Mar 2025 11:29:33 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Addressed Review comments
>  - Addressed Review comments

Looks good with one minor code style issue.

tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 42:

> 40: import test.util.Util;
> 41: 
> 42: public class TextSelectionTest extends RobotTestBase{

Minor: please add a space before the `{`

-------------

PR Review: https://git.openjdk.org/jfx/pull/1719#pullrequestreview-2657216975
PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979308621

From kcr at openjdk.org  Tue Mar  4 12:25:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 12:25:04 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
Message-ID: <vfAdq8Q9T5_gnjd8hkGd-M9XADamt0yoK2Djsi_R52s=.4a8d0f6c-5d32-4ee8-be5b-bd1afc8f7d4a@github.com>

On Mon, 3 Mar 2025 11:29:33 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Addressed Review comments
>  - Addressed Review comments

tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 50:

> 48:     <body>&nbsp&nbsp&nbsp&nbsp some text</body>
> 49:     </html>
> 50:     """;

One more minor code style issue: lines 45-50 should be intended

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979321075

From jvos at openjdk.org  Tue Mar  4 13:02:25 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 13:02:25 GMT
Subject: [jfx21u] RFR: 8340322: Update WebKit to 620.1
Message-ID: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>

Almost clean backport of JDK-8340322
Manually changed:
* modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
* modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

-------------

Commit messages:
 - Backport 1e6915738d654e6cf7a547e47b8b020117db6bc3

Changes: https://git.openjdk.org/jfx21u/pull/92/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8340322
  Stats: 773680 lines in 8156 files changed: 644442 ins; 72180 del; 57058 mod
  Patch: https://git.openjdk.org/jfx21u/pull/92.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/92/head:pull/92

PR: https://git.openjdk.org/jfx21u/pull/92

From snazarki at openjdk.org  Tue Mar  4 13:06:01 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 4 Mar 2025 13:06:01 GMT
Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <W5o_-HHTPr8eciKJWLxD6TUZ5EasjzsqephUwX6MpeQ=.0c046412-0c08-429d-aa51-d13539e59dd7@github.com>
References: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
 <W5o_-HHTPr8eciKJWLxD6TUZ5EasjzsqephUwX6MpeQ=.0c046412-0c08-429d-aa51-d13539e59dd7@github.com>
Message-ID: <Rj-HyI4ifIU7N4Jgo5g3GIEPDlyq4Dy1BKYVDWMpSvU=.6db49380-3547-4546-9f94-f2b5bfd28db8@github.com>

On Tue, 4 Mar 2025 10:47:38 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Hi!
>> 
>> I'd like to backport the commit 22035dec47 that bring updates to GStreamer and Glib:  
>> - 8346228: Update GStreamer to 1.24.10
>> - 8346229: Update Glib to 2.82.4
>> 
>> The original [commit ](https://github.com/openjdk/jfx/commit/22035dec470756e03d254aa12c088876ae20497d) was authored by Alexander Matveev and was reviewed by Joeri Sykora and Kevin Rushforth
>
> These are good to go. Please note that it is more convenient to use the /skara backport jfx21u command as a comment to the original commit. That way, we are guaranteed that the commit is exactly the same as the one in the backport. (I did it manually to check, and all ok here)

Thanks @johanvos, I've missed this feature.

-------------

PR Comment: https://git.openjdk.org/jfx21u/pull/89#issuecomment-2697495172

From duke at openjdk.org  Tue Mar  4 13:06:02 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Mar 2025 13:06:02 GMT
Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
References: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
Message-ID: <wF9Uifno-tp-8rrxLn2-6P6Icc4xeV1cLIuWk8xNQJk=.9998cdde-dff2-4bae-a8b8-484fe0d666c6@github.com>

On Mon, 24 Feb 2025 16:52:38 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> I'd like to backport the commit 22035dec47 that bring updates to GStreamer and Glib:  
> - 8346228: Update GStreamer to 1.24.10
> - 8346229: Update Glib to 2.82.4
> 
> The original [commit ](https://github.com/openjdk/jfx/commit/22035dec470756e03d254aa12c088876ae20497d) was authored by Alexander Matveev and was reviewed by Joeri Sykora and Kevin Rushforth

@snazarkin 
Your change (at version 307b020b1ab004a8e14c9d0b944736e4f0cd097d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx21u/pull/89#issuecomment-2697500408

From kcr at openjdk.org  Tue Mar  4 13:38:19 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 13:38:19 GMT
Subject: [jfx21u] RFR: 8340322: Update WebKit to 620.1
In-Reply-To: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
References: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
Message-ID: <_vpz2QifLreKzBI18-bfQwOHlYZYiPlOfw_jXyfJkPI=.7ba30d02-700f-427b-be14-317ac763f4fd@github.com>

On Tue, 4 Mar 2025 12:55:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8340322
> Manually changed:
> * modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
> * modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

The patch looks good.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx21u/pull/92#pullrequestreview-2657513718

From snazarki at openjdk.org  Tue Mar  4 14:04:03 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Tue, 4 Mar 2025 14:04:03 GMT
Subject: [jfx21u] Integrated: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
References: <J2OVfS5xdIGtE7sbkKTDvrj33jwOCMPakm6Povaj_IE=.305d7c26-50c6-4d06-bc59-d40c910ceb37@github.com>
Message-ID: <vh44z3_o2qr1Pay0fvxtlvlCVaiDFBE3EU1rt6bCVzc=.9b3c0d49-2ac0-491e-b99a-bd61e878224f@github.com>

On Mon, 24 Feb 2025 16:52:38 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> I'd like to backport the commit 22035dec47 that bring updates to GStreamer and Glib:  
> - 8346228: Update GStreamer to 1.24.10
> - 8346229: Update Glib to 2.82.4
> 
> The original [commit ](https://github.com/openjdk/jfx/commit/22035dec470756e03d254aa12c088876ae20497d) was authored by Alexander Matveev and was reviewed by Joeri Sykora and Kevin Rushforth

This pull request has now been integrated.

Changeset: 6734586d
Author:    Sergey Nazarkin <snazarki at openjdk.org>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/6734586db944dc459aaf7ac9a06136475810772b
Stats:     12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod

8346228: Update GStreamer to 1.24.10
8346229: Update Glib to 2.82.4

Backport-of: 22035dec470756e03d254aa12c088876ae20497d

-------------

PR: https://git.openjdk.org/jfx21u/pull/89

From duke at openjdk.org  Tue Mar  4 14:51:02 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Tue, 4 Mar 2025 14:51:02 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
Message-ID: <xeMj-zb5V5yNG7cFvNx-jzQwnZQmqae7842JJcM4UAA=.55fbd55e-a1e1-4b15-9fb4-12f9bd6683ca@github.com>

On Fri, 28 Feb 2025 15:56:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md

Marked as reviewed by abhinayagarwal at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2657868437

From angorya at openjdk.org  Tue Mar  4 15:33:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 15:33:19 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v8]
In-Reply-To: <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
Message-ID: <kUmmvHC5a3FZgpZrhPSQIfdtlEIDm9W7vwpFiI2PEtk=.b8dde559-c56a-416d-b9b0-860ea769493e@github.com>

On Thu, 30 Jan 2025 23:02:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
>> 
>> Removed earlier manual tester in favor of the monkey tester.
>> 
>> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

woo hoo!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2698034810

From angorya at openjdk.org  Tue Mar  4 15:36:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 15:36:11 GMT
Subject: Integrated: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale
In-Reply-To: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
Message-ID: <CUSvqAPKHEVi1MzxAE1NBOau2-zy28ovrKWtfRCsE68=.b4c8c5b8-6f56-4827-a550-8c397da88de0@github.com>

On Thu, 15 Jun 2023 19:38:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
> 
> Removed earlier manual tester in favor of the monkey tester.
> 
> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).

This pull request has now been integrated.

Changeset: 1824db5c
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1824db5c7183b5b3749fe4c29baae51f34dcc421
Stats:     1172 lines in 8 files changed: 149 ins; 933 del; 90 mod

8299753: Tree/TableView: Column Resizing With Fractional Scale
8299755: Tree/TableView: Cursor Decouples From Divider When Resizing With Fractional Scale

Reviewed-by: kcr, arapte, kpk

-------------

PR: https://git.openjdk.org/jfx/pull/1156

From angorya at openjdk.org  Tue Mar  4 15:41:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 15:41:09 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <7_S-ofCWiMT4jMMpBgmtfLcRazXxFLbi6B4hLkEUQx0=.93ee212e-b612-4d5b-8de1-29925c6207c2@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <8PtPXD8hTVpzl0XixxqhNiN1rDeyWp9hBvbcikFd2bI=.ec693954-976e-47dd-8256-37c2bafa6886@github.com>
 <7_S-ofCWiMT4jMMpBgmtfLcRazXxFLbi6B4hLkEUQx0=.93ee212e-b612-4d5b-8de1-29925c6207c2@github.com>
Message-ID: <fbUU0YFOvGyzf2c4n9n5PpBvIJx8iLeZkDntkWdsEaQ=.71579fe5-f6ee-4bf3-a480-a2b83c4ac439@github.com>

On Mon, 3 Mar 2025 11:53:34 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 97:
>> 
>>> 95: 
>>> 96:         int x = (int)(scene.getWindow().getX() + scene.getX() + 22);
>>> 97:         int y = (int)(scene.getWindow().getY() + scene.getY() + 15);
>> 
>> can these offsets (22, 15) be measured instead of hard-coded?
>
> We are not getting the text area from web view. This point is used to simulate the mouse click.

so they are arbitrary, and will work for every font size?

(The default font size varies depending on the platform and other circumstances, see `PrismFontFactory::getSystemFontSize()` - though I am not sure if the default font size is picked up by the `WebView`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979709600

From angorya at openjdk.org  Tue Mar  4 15:48:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 15:48:05 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
Message-ID: <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>

On Mon, 3 Mar 2025 11:29:33 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Addressed Review comments
>  - Addressed Review comments

tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 53:

> 51: 
> 52:     private static CountDownLatch webviewLoadLatch = new CountDownLatch(1);
> 53:     private Color colorBefore;

suggestion: make `colorBefore/After` _volatile_ since they are being accessed from different threads without any synchronization.
I think this should be sufficient (no need for `AtomicReference`).

tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 89:

> 87:         Util.runAndWait(() -> colorAfter = robot.getPixelColor(x, y));
> 88: 
> 89:         Assertions.assertNotEquals(colorBefore, colorAfter,

should we also test for non-null `colorBefore` ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979719322
PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979721955

From angorya at openjdk.org  Tue Mar  4 15:50:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 15:50:11 GMT
Subject: RFR: 8299753: Tree/TableView: Column Resizing With Fractional
 Scale [v8]
In-Reply-To: <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
References: <_qE4KSf9FXN_l5RfnXaB-YL52OBRgeewCzmk4th2S-k=.3376b0e5-e208-4aa2-9edc-2115a9327a78@github.com>
 <C8iNHXeVc0fWxtbk6FiMA78h-jwy4apoRoS-BRGKKGc=.955357d0-2cdf-4753-94e9-c1b6aaafd381@github.com>
Message-ID: <fLEUhaVTxWHZvMkgYuD1gQydHQ6jpPgVBy57ncLf6jU=.926a9e9a-b661-4f21-bf06-6ad9f57c5156@github.com>

On Thu, 30 Jan 2025 23:02:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Modified the resize algorithm to work well with fractional scale, thanks for deeper understanding of the problem thanks to  @hjohn and @mstr2 .
>> 
>> Removed earlier manual tester in favor of the monkey tester.
>> 
>> It is important to note that even though the constraints are given by the user in unsnapped coordinates, they are converted to snapped values, since the snapped values correspond to the actual pixels on the display.  This means the tests that validate honoring constraints should, in all the cases where (scale != 1.0), assume possibly error not exceeding (1.0 / scale).
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Thank you everyone who helped with this PR over the years!   :-)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1156#issuecomment-2698091283

From angorya at openjdk.org  Tue Mar  4 16:16:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 16:16:21 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread
Message-ID: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>

Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.

-------------

Commit messages:
 - spelling
 - use system menu
 - cleanup
 - possible fix
 - test

Changes: https://git.openjdk.org/jfx/pull/1727/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1727&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350976
  Stats: 67 lines in 2 files changed: 56 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1727.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1727/head:pull/1727

PR: https://git.openjdk.org/jfx/pull/1727

From kcr at openjdk.org  Tue Mar  4 16:18:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 16:18:13 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
Message-ID: <AN7Jpb1MT27GPHKoS7LoLCRpm7J-sjjy3ebwITdQQjo=.41a3e20f-2bc7-47e4-a521-41db4dad3767@github.com>

On Tue, 4 Mar 2025 15:43:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Addressed Review comments
>>  - Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 53:
> 
>> 51: 
>> 52:     private static CountDownLatch webviewLoadLatch = new CountDownLatch(1);
>> 53:     private Color colorBefore;
> 
> suggestion: make `colorBefore/After` _volatile_ since they are being accessed from different threads without any synchronization.
> I think this should be sufficient (no need for `AtomicReference`).

This isn't strictly needed, since `runAndWait` synchronizes the two threads (although there is no harm in adding volatile).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979767937

From angorya at openjdk.org  Tue Mar  4 16:22:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 16:22:05 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <AN7Jpb1MT27GPHKoS7LoLCRpm7J-sjjy3ebwITdQQjo=.41a3e20f-2bc7-47e4-a521-41db4dad3767@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
 <AN7Jpb1MT27GPHKoS7LoLCRpm7J-sjjy3ebwITdQQjo=.41a3e20f-2bc7-47e4-a521-41db4dad3767@github.com>
Message-ID: <AEDzXdkkDST_o6oWV4wN7IMksPypkpTRkmhUKCtm2gc=.5c5eb909-1092-4938-92e8-5343100aaad0@github.com>

On Tue, 4 Mar 2025 16:09:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 53:
>> 
>>> 51: 
>>> 52:     private static CountDownLatch webviewLoadLatch = new CountDownLatch(1);
>>> 53:     private Color colorBefore;
>> 
>> suggestion: make `colorBefore/After` _volatile_ since they are being accessed from different threads without any synchronization.
>> I think this should be sufficient (no need for `AtomicReference`).
>
> This isn't strictly needed, since `runAndWait` synchronizes the two threads (although there is no harm in adding volatile).

https://en.wikipedia.org/wiki/Cache_coherence

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979787974

From jvos at openjdk.org  Tue Mar  4 16:28:17 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:28:17 GMT
Subject: [jfx21u] RFR: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <1Cyos9KIz4MyGuP-XAJleBGKMjUSkz8U07bHduGCk_k=.ae309274-7f2d-4409-82a3-aa902626c6b7@github.com>
References: <1Cyos9KIz4MyGuP-XAJleBGKMjUSkz8U07bHduGCk_k=.ae309274-7f2d-4409-82a3-aa902626c6b7@github.com>
Message-ID: <rELQIox-KP4nXb3Ax6ObH-xx9Z7iKgB4RljJJIOz1o8=.8838c93a-eb70-4a63-a368-7f7f3d199e8d@github.com>

On Tue, 4 Mar 2025 10:22:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 22035dec from the openjdk/jfx repository.
> 
> The commit being backported was authored by Alexander Matveev on 14 Jan 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

dup of #89

-------------

PR Comment: https://git.openjdk.org/jfx21u/pull/90#issuecomment-2698234799

From jvos at openjdk.org  Tue Mar  4 16:28:17 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:28:17 GMT
Subject: [jfx21u] Withdrawn: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <1Cyos9KIz4MyGuP-XAJleBGKMjUSkz8U07bHduGCk_k=.ae309274-7f2d-4409-82a3-aa902626c6b7@github.com>
References: <1Cyos9KIz4MyGuP-XAJleBGKMjUSkz8U07bHduGCk_k=.ae309274-7f2d-4409-82a3-aa902626c6b7@github.com>
Message-ID: <PkWBR0LXVk5iy7dWXnmIHD9rJ3tXYXgtUlR-Bs45D6g=.a8fb38ef-f1af-4a39-8f87-8f5f7e8c70d8@github.com>

On Tue, 4 Mar 2025 10:22:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 22035dec from the openjdk/jfx repository.
> 
> The commit being backported was authored by Alexander Matveev on 14 Jan 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx21u/pull/90

From kcr at openjdk.org  Tue Mar  4 16:30:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 16:30:10 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
Message-ID: <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>

On Mon, 3 Mar 2025 21:42:26 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The above does require though that `Platform.accessibilityActiveProperty()` is properly synchronized.  I think it may be a good idea to fix that first.  Perhaps all platform provided properties (if there are more) should ensure they're only initialized once.
>
> unrelated, but I would rather disallow background access to any platform properties.
> 
> _per the earlier email_, this might (read: will) create concurrent access when the node is not yet attached to the scene graph:
> 
> 
> background thread                   fx app thread
> 1. start creating the node
> 2. add listener to platform prop
> 3. keep initializing the node        <-- platform property change notification
> 4. some more code
> 
> 
> step 3 is when concurrent access occurs.

There is an even more fundamental problem: JavaFX properties are not thread-safe. You cannot safely add a listener or binding to a property in one thread while another thread modifies that property's value.

So I think that deferring the binding to `Platform::accessibilityActiveProperty` is the only viable approach.There might still be an opportunity to simplify it a bit along the lines of what John mentions, as long as the code that binds to the property is guaranteed to be run on  the FX application thread.

We can be certain that setting the window property to a non-null value only happens on the FX app thread (`Stage::setScene` enforces that threading constraint).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1979801247

From jvos at openjdk.org  Tue Mar  4 16:32:10 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:32:10 GMT
Subject: [jfx21u] Integrated: 8340322: Update WebKit to 620.1
In-Reply-To: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
References: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
Message-ID: <zs42ajlkCOqwHUUmqjOmCTWhVCaU8HG-rM_6Oy-o_tk=.391e664e-5adc-42fd-b7bd-c7c8cda3a808@github.com>

On Tue, 4 Mar 2025 12:55:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8340322
> Manually changed:
> * modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
> * modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

This pull request has now been integrated.

Changeset: dcd03715
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/dcd037159e1715af03f424e8630c94f0045fd1fa
Stats:     773680 lines in 8156 files changed: 644442 ins; 72180 del; 57058 mod

8340322: Update WebKit to 620.1

Reviewed-by: kcr
Backport-of: 1e6915738d654e6cf7a547e47b8b020117db6bc3

-------------

PR: https://git.openjdk.org/jfx21u/pull/92

From jvos at openjdk.org  Tue Mar  4 16:44:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:44:22 GMT
Subject: [jfx21u] Integrated: 8349891: Not implemented function should have
 printf
Message-ID: <idfoEmzd-qBkqzo_9eWRhnw7EjxEQkj3voawRue3DD4=.d687d2cd-681a-46a3-8591-ad4f59954635@github.com>

Hi all,

This pull request contains a backport of commit 065548d0 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 18 Feb 2025 and was reviewed by Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 065548d09dd4909137343e7e9eb2d25a336a34dd

Changes: https://git.openjdk.org/jfx21u/pull/93/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=93&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349891
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx21u/pull/93.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/93/head:pull/93

PR: https://git.openjdk.org/jfx21u/pull/93

From jvos at openjdk.org  Tue Mar  4 16:44:22 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:44:22 GMT
Subject: [jfx21u] Integrated: 8349891: Not implemented function should have
 printf
In-Reply-To: <idfoEmzd-qBkqzo_9eWRhnw7EjxEQkj3voawRue3DD4=.d687d2cd-681a-46a3-8591-ad4f59954635@github.com>
References: <idfoEmzd-qBkqzo_9eWRhnw7EjxEQkj3voawRue3DD4=.d687d2cd-681a-46a3-8591-ad4f59954635@github.com>
Message-ID: <TChuZd--Z1z4Gq99hv6ZCKt2nBcgYOkcX9tp62viokE=.8bfe45a3-5da3-47c5-a712-d8d32d699837@github.com>

On Tue, 4 Mar 2025 16:37:54 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 065548d0 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 18 Feb 2025 and was reviewed by Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b2c9c466
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/b2c9c466314a0177ce6173831f61c668e9efa704
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8349891: Not implemented function should have printf

Backport-of: 065548d09dd4909137343e7e9eb2d25a336a34dd

-------------

PR: https://git.openjdk.org/jfx21u/pull/93

From jvos at openjdk.org  Tue Mar  4 16:48:29 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:48:29 GMT
Subject: [jfx21u] Integrated: 8349924: Additional WebKit 620.1 fixes from
 WebKitGTK 2.46.6
Message-ID: <XZUjpLsSjwexESQPM75f08z3J-jpIhwqh31nZshbgmI=.53e2c6e3-4ea9-4b63-be19-47b5d27382fd@github.com>

Hi all,

This pull request contains a backport of commit f38ab33b from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 25 Feb 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

-------------

Commit messages:
 - Backport f38ab33b296de7b0bf5b306e4803de8c686e2a83

Changes: https://git.openjdk.org/jfx21u/pull/94/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=94&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349924
  Stats: 2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod
  Patch: https://git.openjdk.org/jfx21u/pull/94.diff
  Fetch: git fetch https://git.openjdk.org/jfx21u.git pull/94/head:pull/94

PR: https://git.openjdk.org/jfx21u/pull/94

From jvos at openjdk.org  Tue Mar  4 16:48:30 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 16:48:30 GMT
Subject: [jfx21u] Integrated: 8349924: Additional WebKit 620.1 fixes from
 WebKitGTK 2.46.6
In-Reply-To: <XZUjpLsSjwexESQPM75f08z3J-jpIhwqh31nZshbgmI=.53e2c6e3-4ea9-4b63-be19-47b5d27382fd@github.com>
References: <XZUjpLsSjwexESQPM75f08z3J-jpIhwqh31nZshbgmI=.53e2c6e3-4ea9-4b63-be19-47b5d27382fd@github.com>
Message-ID: <bqjgQmIzE8yLBuUURiX545_2ZsXzYZpqP9txi8iO6Dc=.729a2834-d069-4482-ad7c-2ff908edaa43@github.com>

On Tue, 4 Mar 2025 16:42:55 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit f38ab33b from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 25 Feb 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 3f2c909d
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx21u/commit/3f2c909dc0d115e3ad31dc56e96a87fdddf4d151
Stats:     2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod

8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6

Backport-of: f38ab33b296de7b0bf5b306e4803de8c686e2a83

-------------

PR: https://git.openjdk.org/jfx21u/pull/94

From kcr at openjdk.org  Tue Mar  4 17:17:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 17:17:07 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v4]
In-Reply-To: <HuhiRUAlQcR5o2EWZ335j-DESuBDtY3sdgzOvussNnI=.e8954186-29eb-4a63-8b05-6c07cb58c27f@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <HuhiRUAlQcR5o2EWZ335j-DESuBDtY3sdgzOvussNnI=.e8954186-29eb-4a63-8b05-6c07cb58c27f@github.com>
Message-ID: <W4yLtRt1pu5vwp65-tIPdDnoxlvq0IwGrmAPjthLa7M=.24f6783b-1e50-47bc-b05f-467b2662e2cb@github.com>

On Fri, 28 Feb 2025 21:09:37 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - enforced fx application thread
>> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
>> - clarified `ComboBoxBase::show`
>> - added a headful test `TestThreadingRestrictions`
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

All looks good now.

Have you done a headful test run?

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1717#pullrequestreview-2658376256

From kcr at openjdk.org  Tue Mar  4 17:53:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 17:53:01 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <AEDzXdkkDST_o6oWV4wN7IMksPypkpTRkmhUKCtm2gc=.5c5eb909-1092-4938-92e8-5343100aaad0@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
 <AN7Jpb1MT27GPHKoS7LoLCRpm7J-sjjy3ebwITdQQjo=.41a3e20f-2bc7-47e4-a521-41db4dad3767@github.com>
 <AEDzXdkkDST_o6oWV4wN7IMksPypkpTRkmhUKCtm2gc=.5c5eb909-1092-4938-92e8-5343100aaad0@github.com>
Message-ID: <_b8vEPblzjpx6o0oxaoNSsaqEqzAbQYB4VwDfcJwk2I=.8aa4c5b9-d3f7-4e1b-b2e7-5779e186fe80@github.com>

On Tue, 4 Mar 2025 16:19:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> https://en.wikipedia.org/wiki/Cache_coherence

That's interesting, but not particularly relevant. What is relevant is the JVM spec, specifically the Java Memory Model, which guarantees a happens-before ordering of actions in two threads that synchronize-with each other.

> edit: you might be right about runAndWait, we know it does separate the access from multiple threads in time, and it might be even smart enough to figure out that the field is being accessed from two different threads and emit the appropriate bytecode (similarly how we don't need the `final` keyword for effectively final variables nowadays).

It isn't about the byte code that is emitted as much as it is about how the code is executed by the two different threads. And it isn't because it need to be "smart enough", it's because that's how the memory model works.

A write by the thread that executes the runnable passed into runAndWait (the FX app thread in this case), happens-before the read done by the test thread that is done after the runAndWait returns because the runAndWait call causes the actions done in the runAndWait's runnable to synchronize-with the wait done by the calling thread.

> But I think that adding `volatile` **_guarantees_** that all the necessary steps are done by the JVM.

Yes, adding `volatile` guarantees the appropriate happens-before relationship. But so does synchronizing.

I don't really care one way or the other in this case.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1979939639

From angorya at openjdk.org  Tue Mar  4 18:23:45 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 18:23:45 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v8]
In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
Message-ID: <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>

> Root Cause:
> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
> 
> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
> 
> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
> 
> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
> 
> With this change, it is safe to create and populate charts with data in a background thread.
> 
> ---
> 
> ## NOTES
> 
> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
> 
> ## Note to the Reviewers
> 
> To avoid merge conflicts, the preferred order of integrations:
> 
> #1697 
> #1713 
> #1717

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - use subscription
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - unnecessary
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
 - enabled pie chart test
 - Merge branch 'master' into 8349091.charts.thread.safety
 - ... and 19 more: https://git.openjdk.org/jfx/compare/1824db5c...fc40e9d6

-------------

Changes: https://git.openjdk.org/jfx/pull/1697/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=07
  Stats: 316 lines in 11 files changed: 176 ins; 101 del; 39 mod
  Patch: https://git.openjdk.org/jfx/pull/1697.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697

PR: https://git.openjdk.org/jfx/pull/1697

From nlisker at openjdk.org  Tue Mar  4 18:28:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 4 Mar 2025 18:28:06 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
Message-ID: <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>

On Fri, 28 Feb 2025 15:56:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md

doc-files/notes/24/JDK-8340852-ScrollPane.md line 7:

> 5: The fix for [JDK-8340852](https://bugs.openjdk.org/browse/JDK-8340852) changed the behavior of `ScrollPane`. With the latest update, `ScrollPane` only responds to keyboard navigation when it is the focused node. If you prefer the previous behavior, where `ScrollPane` always reacts to arrow keys and other navigational inputs, you can manually restore it by adding an event handler:
> 6: 
> 7: ```

Syntax highlighting:
Suggestion:

doc-files/notes/24/JDK-8340852-ScrollPane.md line 31:

> 29: ```
> 30: Using this helper method to convert scroll fractions to values for the scrollbars, and set them:
> 31: ```

Suggestion:

doc-files/notes/24/JDK-8340852-ScrollPane.md line 54:

> 52: }
> 53: ```
> 54: Adding this event handler will make ScrollPane react to navigation keys as it did before the update.

Suggestion:

Adding this event handler will make `ScrollPane` react to navigation keys as it did before the update.

doc-files/release-notes-24.md line 70:

> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
> 69: 
> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the IIORegistry class. Refer to the Java Image I/O documentation for more information.

"Refer to the Java Image I/O documentation for more information."

Perhaps give a link to the Image I/O documentation?

doc-files/release-notes-24.md line 134:

> 132: [JDK-8343398](https://bugs.openjdk.org/browse/JDK-8343398) | Add reducedData preference | graphics
> 133: [JDK-8345188](https://bugs.openjdk.org/browse/JDK-8345188) | Support tree-structural pseudo-classes | scenegraph
> 134: 

Should we give a link to https://openjfx.io/javadoc/24/new-list.html to easily see new API (when the docs are published)? Maybe even to https://openjfx.io/javadoc/24/deprecated-list.html.

doc-files/release-notes-24.md line 191:

> 189: [JDK-8338701](https://bugs.openjdk.org/browse/JDK-8338701) | Provide media support for libavcodec version 61 | media
> 190: [JDK-8346228](https://bugs.openjdk.org/browse/JDK-8346228) | Update GStreamer to 1.24.10 | media
> 191: [JDK-8346229](https://bugs.openjdk.org/browse/JDK-8346229) | Update Glib to 2.82.4 | media

I'm not sure it's beneficial to include obsolete version updates. If the final update of a dependency is to 1.2.3, then any previous update (1.2.1) doesn't need to be listed, in my opinion.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979919965
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979920275
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979921855
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979912329
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979951972
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1979985574

From angorya at openjdk.org  Tue Mar  4 18:30:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 18:30:01 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v8]
In-Reply-To: <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
Message-ID: <lhu1Yh6t6I4OT6dJakArPfVdCxg7xsauNGDiPRb0GZs=.3c8482da-55c2-42d2-91cc-84ce50b04d1f@github.com>

On Tue, 4 Mar 2025 18:23:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - use subscription
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - unnecessary
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - enabled pie chart test
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - ... and 19 more: https://git.openjdk.org/jfx/compare/1824db5c...fc40e9d6

Modified to use Subscription (thanks, @hjohn !)

Check out the code sample

https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/tests/Chart_ThreadInitTest.java 

which exercises the scenario.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2698541157

From kcr at openjdk.org  Tue Mar  4 18:52:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 18:52:01 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <j7veVUPf1YEPX5D5SjBn-zy5VA8RjCHrmI4jZmrPNPE=.adc3696f-24f5-44da-9b00-8903979c784a@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <CvkS7J6L4lVBchrmVUaaf7we91sQl8GPv6x4m8FgbdA=.aaceadcb-5741-4108-9b40-2b118f243c5f@github.com>
 <j7veVUPf1YEPX5D5SjBn-zy5VA8RjCHrmI4jZmrPNPE=.adc3696f-24f5-44da-9b00-8903979c784a@github.com>
Message-ID: <-z28Qr5S87a6kz8791OUCnd20v8fRVv9UY5ohoQrCHc=.35a67799-8b25-4d8a-9207-b45524101d31@github.com>

On Fri, 28 Feb 2025 18:24:38 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 106:
>> 
>>> 104: 
>>> 105:     // SimpleBooleanProperty or ObjectBinding
>>> 106:     private volatile Object accessibilityActive;
>> 
>> You can use `ObservableValue<?>` instead of `Object` as the type. Alternatively, use two fields, a `SimpleBooleanProperty` for use by the FX app thread and an ObjectBinding for use by a background thread. They wouldn't need to be volatile in that case. What you have is OK, but using two properties might simplify the logic a bit.
>
> It's a design decision - I won't want to waste an extra pointer.
> The cpu cycles are much cheaper nowadays than bytes.
> Extra bytes cost much more in cpu cycles (gc) and electricity.

While I still think the code would be cleaner with two properties, and the extra memory is not significant, what you have will work, so I won't object.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980035825

From kcr at openjdk.org  Tue Mar  4 18:52:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 18:52:00 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v8]
In-Reply-To: <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
Message-ID: <9vLZF1_Do3hbq6_tb_pXTmzvUVXcPWpf6C3GdcxgRjo=.dc51a4a8-5895-4498-a8a6-32d6b5221268@github.com>

On Tue, 4 Mar 2025 18:23:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - use subscription
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - unnecessary
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - enabled pie chart test
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - ... and 19 more: https://git.openjdk.org/jfx/compare/1824db5c...fc40e9d6

I'll do some more testing, but this looks OK to me.

modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 563:

> 561:                     .subscribe((w) -> {
> 562:                         if (w != null) {
> 563:                             // also unsubscribes when appears in a window

Suggestion: Add a comment that this can only happen on the FX app thread, since you are relying on that.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2658633362
PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980031738

From angorya at openjdk.org  Tue Mar  4 19:12:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 19:12:34 GMT
Subject: RFR: 8351067: doc: Clarify Platform::accessibilityActive threading use
Message-ID: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>

Changed the spec to require access only from the FX application thread.

-------------

Commit messages:
 - javadoc

Changes: https://git.openjdk.org/jfx/pull/1728/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351067
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1728/head:pull/1728

PR: https://git.openjdk.org/jfx/pull/1728

From kcr at openjdk.org  Tue Mar  4 19:32:52 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 19:32:52 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v8]
In-Reply-To: <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
Message-ID: <SZYFh1bFVoUPr-BeIoCpC0xN__1xozlWko8LpxZVpQM=.fded46cf-e06f-430d-82f6-ee516c8c877b@github.com>

On Tue, 4 Mar 2025 18:23:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - use subscription
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - unnecessary
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>  - enabled pie chart test
>  - Merge branch 'master' into 8349091.charts.thread.safety
>  - ... and 19 more: https://git.openjdk.org/jfx/compare/1824db5c...fc40e9d6

All my testing looks good.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2658757265

From angorya at openjdk.org  Tue Mar  4 19:32:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 19:32:51 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v9]
In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
Message-ID: <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>

> Root Cause:
> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
> 
> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
> 
> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
> 
> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
> 
> With this change, it is safe to create and populate charts with data in a background thread.
> 
> ---
> 
> ## NOTES
> 
> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
> 
> ## Note to the Reviewers
> 
> To avoid merge conflicts, the preferred order of integrations:
> 
> #1697 
> #1713 
> #1717

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1697/files
  - new: https://git.openjdk.org/jfx/pull/1697/files/fc40e9d6..509c0519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1697&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1697.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1697/head:pull/1697

PR: https://git.openjdk.org/jfx/pull/1697

From angorya at openjdk.org  Tue Mar  4 19:32:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 19:32:54 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v8]
In-Reply-To: <9vLZF1_Do3hbq6_tb_pXTmzvUVXcPWpf6C3GdcxgRjo=.dc51a4a8-5895-4498-a8a6-32d6b5221268@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <Nz_76gCJkGrHXXKc9-AfbenUD4Um9L1GUHHfPaqzii4=.b6589482-e65e-415f-a399-df4ee387842a@github.com>
 <9vLZF1_Do3hbq6_tb_pXTmzvUVXcPWpf6C3GdcxgRjo=.dc51a4a8-5895-4498-a8a6-32d6b5221268@github.com>
Message-ID: <Y_jsSyciSPEBQi5ZNWxb7I_pc2FxwszUseJMEpwbLXw=.eabc70dc-2d83-4a10-ad11-f5c19c44887a@github.com>

On Tue, 4 Mar 2025 18:44:41 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - use subscription
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - unnecessary
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - Merge remote-tracking branch 'origin/master' into 8349091.charts.thread.safety
>>  - enabled pie chart test
>>  - Merge branch 'master' into 8349091.charts.thread.safety
>>  - ... and 19 more: https://git.openjdk.org/jfx/compare/1824db5c...fc40e9d6
>
> modules/javafx.controls/src/main/java/javafx/scene/chart/Chart.java line 563:
> 
>> 561:                     .subscribe((w) -> {
>> 562:                         if (w != null) {
>> 563:                             // also unsubscribes when appears in a window
> 
> Suggestion: Add a comment that this can only happen on the FX app thread, since you are relying on that.

added comment

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980106105

From jhendrikx at openjdk.org  Tue Mar  4 19:32:53 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 4 Mar 2025 19:32:53 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
Message-ID: <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>

On Tue, 4 Mar 2025 16:27:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> unrelated, but I would rather disallow background access to any platform properties.
>> 
>> _per the earlier email_, this might (read: will) create concurrent access when the node is not yet attached to the scene graph:
>> 
>> 
>> background thread                   fx app thread
>> 1. start creating the node
>> 2. add listener to platform prop
>> 3. keep initializing the node        <-- platform property change notification
>> 4. some more code
>> 
>> 
>> step 3 is when concurrent access occurs.
>
> There is an even more fundamental problem: JavaFX properties are not thread-safe. You cannot safely add a listener or binding to a property in one thread while another thread modifies that property's value.
> 
> So I think that deferring the binding to `Platform::accessibilityActiveProperty` is the only viable approach.There might still be an opportunity to simplify it a bit along the lines of what John mentions, as long as the code that binds to the property is guaranteed to be run on  the FX application thread.
> 
> We can be certain that setting the window property to a non-null value only happens on the FX app thread (`Stage::setScene` enforces that threading constraint).

@kevinrushforth I don't know, I would think it should be possible to create a property or property wrapper to make it thread-safe.  Just having a version with all its methods synchronized is probably sufficient.  If that saves a lot of complex logic in, what looks like, dozens of controls, then it seems like a far better solution to me.  Of course, that should only apply to special properties; I'm not suggesting making all properties synchronized -- although I think we could as, without contention (since they're supposed to be used from a single thread), it would be nearly free, and it would make all kinds of undefined behavior scenario's when used from multiple threads (by accident or otherwise) suddenly deterministic and debuggable.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980107096

From jhendrikx at openjdk.org  Tue Mar  4 19:37:08 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 4 Mar 2025 19:37:08 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
Message-ID: <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>

On Tue, 4 Mar 2025 19:28:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> There is an even more fundamental problem: JavaFX properties are not thread-safe. You cannot safely add a listener or binding to a property in one thread while another thread modifies that property's value.
>> 
>> So I think that deferring the binding to `Platform::accessibilityActiveProperty` is the only viable approach.There might still be an opportunity to simplify it a bit along the lines of what John mentions, as long as the code that binds to the property is guaranteed to be run on  the FX application thread.
>> 
>> We can be certain that setting the window property to a non-null value only happens on the FX app thread (`Stage::setScene` enforces that threading constraint).
>
> @kevinrushforth I don't know, I would think it should be possible to create a property or property wrapper to make it thread-safe.  Just having a version with all its methods synchronized is probably sufficient.  If that saves a lot of complex logic in, what looks like, dozens of controls, then it seems like a far better solution to me.  Of course, that should only apply to special properties; I'm not suggesting making all properties synchronized -- although I think we could as, without contention (since they're supposed to be used from a single thread), it would be nearly free, and it would make all kinds of undefined behavior scenario's when used from multiple threads (by accident or otherwise) suddenly deterministic and debuggable.

I think the problem is in the callbacks themselves, as they'd be on the wrong thread.  I vaguely remember experimenting with a system where you can provide an Executor for callbacks (like `Platform::runLater`) to mitigate this.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980114654

From angorya at openjdk.org  Tue Mar  4 20:05:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 20:05:02 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v4]
In-Reply-To: <W4yLtRt1pu5vwp65-tIPdDnoxlvq0IwGrmAPjthLa7M=.24f6783b-1e50-47bc-b05f-467b2662e2cb@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <HuhiRUAlQcR5o2EWZ335j-DESuBDtY3sdgzOvussNnI=.e8954186-29eb-4a63-8b05-6c07cb58c27f@github.com>
 <W4yLtRt1pu5vwp65-tIPdDnoxlvq0IwGrmAPjthLa7M=.24f6783b-1e50-47bc-b05f-467b2662e2cb@github.com>
Message-ID: <Kd_1JWgd6W_owUpO8EpUV4N1zIpO47p_zBHOUQ661gY=.125d3d30-0993-40bf-b04e-a345fefdd7a6@github.com>

On Tue, 4 Mar 2025 17:14:26 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Have you done a headful test run?

combined branch (this PR + #1697 + #1727) is green on all platforms except for a single unrelated failure on linux: 

`RegionBackgroundFillUITest > testScenario1() FAILED`

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1717#issuecomment-2698771906

From jvos at openjdk.org  Tue Mar  4 20:23:42 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 20:23:42 GMT
Subject: [jfx17u] RFR: 8336940: Update GStreamer to 1.24.6
Message-ID: <sPX4FO_ALqxuvfFdU6WBWjlK77hxlFJKTKePGKqA1mU=.389500dc-51a3-4235-9d39-f3624912a777@github.com>

Almost clean backport of https://github.com/openjdk/jfx/commit/b88ac0495650bd033ba11e3131e9bffc517872eb

There are 2 manual changes:
1. modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c is not part of jfx17u
2. modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux.c had a merge conflict, since jfx17u doesn't have JDK-8277309
3.

-------------

Commit messages:
 - Backport b88ac0495650bd033ba11e3131e9bffc517872eb

Changes: https://git.openjdk.org/jfx17u/pull/225/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=225&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336940
  Stats: 24537 lines in 328 files changed: 12972 ins; 6876 del; 4689 mod
  Patch: https://git.openjdk.org/jfx17u/pull/225.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/225/head:pull/225

PR: https://git.openjdk.org/jfx17u/pull/225

From kcr at openjdk.org  Tue Mar  4 20:29:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 20:29:07 GMT
Subject: [jfx21u] RFR: 8340322: Update WebKit to 620.1
In-Reply-To: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
References: <KmsLviyq9QO01OC0bsws--xFL7-Q6bZURChHP1aKgaM=.53a0e379-9116-4263-a682-72af19f220e8@github.com>
Message-ID: <bGcxiMXPA8bW_H-RBXoBIA27Hb4eIg1F-4kGb4x7OpU=.96569099-c60c-4137-b1e7-5f79dc95bc8f@github.com>

On Tue, 4 Mar 2025 12:55:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8340322
> Manually changed:
> * modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
> * modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

Because of the differences between the mainline patch and this PR, Skara should not have marked this as clean. I filed https://bugs.openjdk.org/browse/SKARA-2454 to track this.

-------------

PR Comment: https://git.openjdk.org/jfx21u/pull/92#issuecomment-2698828445

From kcr at openjdk.org  Tue Mar  4 20:31:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 20:31:08 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v9]
In-Reply-To: <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
Message-ID: <Mcvq5ZaDriZxw9aEWC54EcriwSI7eHnk5OHwqrhFJfc=.44b0f5fb-763a-4dd1-8c23-4a7ac474ae20@github.com>

On Tue, 4 Mar 2025 19:32:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2658912245

From kcr at openjdk.org  Tue Mar  4 20:41:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 20:41:57 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
Message-ID: <inoKbcfV10oIpV5AgHa3dx4w-w3bmW6DupzyLkj9nZ4=.3207f71d-39ef-4f61-9a41-92db527382ef@github.com>

On Tue, 4 Mar 2025 15:45:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Addressed Review comments
>>  - Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 89:
> 
>> 87:         Util.runAndWait(() -> colorAfter = robot.getPixelColor(x, y));
>> 88: 
>> 89:         Assertions.assertNotEquals(colorBefore, colorAfter,
> 
> should we also test for non-null `colorBefore` ?

`Robot::getPixelColor` can't return null (although I checked the docs and we don't specify one way or the other). It seems fine either way.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980191902

From angorya at openjdk.org  Tue Mar  4 20:41:58 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 20:41:58 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <inoKbcfV10oIpV5AgHa3dx4w-w3bmW6DupzyLkj9nZ4=.3207f71d-39ef-4f61-9a41-92db527382ef@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
 <inoKbcfV10oIpV5AgHa3dx4w-w3bmW6DupzyLkj9nZ4=.3207f71d-39ef-4f61-9a41-92db527382ef@github.com>
Message-ID: <8a-U0rUEAckOyWo1B_WPd84V8SWfBEvksseuwx7WlNc=.4fed9618-81b7-482c-8a8d-4489dd932552@github.com>

On Tue, 4 Mar 2025 20:37:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 89:
>> 
>>> 87:         Util.runAndWait(() -> colorAfter = robot.getPixelColor(x, y));
>>> 88: 
>>> 89:         Assertions.assertNotEquals(colorBefore, colorAfter,
>> 
>> should we also test for non-null `colorBefore` ?
>
> `Robot::getPixelColor` can't return null (although I checked the docs and we don't specify one way or the other). It seems fine either way.

what if the lambdas never run?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980195423

From kcr at openjdk.org  Tue Mar  4 20:48:56 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 20:48:56 GMT
Subject: RFR: 8351067: doc: Clarify Platform::accessibilityActive threading
 use
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <BcLv8hrPUV6XyNs5bs0SOCyTC0lwYqDsILvj7MO6seo=.31fec63f-fbac-43ad-b44e-dba56e0764cf@github.com>

On Tue, 4 Mar 2025 19:00:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Changed the spec to require access only from the FX application thread.

One wording suggestion, but otherwise looks fine.

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 425:

> 423:      * information about any JavaFX window or its children.
> 424:      * <p>
> 425:      * This property can be accessed only from the FX application thread.

"FX application thread" --> "JavaFX Application Thread"

-------------

PR Review: https://git.openjdk.org/jfx/pull/1728#pullrequestreview-2658945736
PR Review Comment: https://git.openjdk.org/jfx/pull/1728#discussion_r1980202460

From angorya at openjdk.org  Tue Mar  4 20:52:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 20:52:39 GMT
Subject: RFR: 8351067: doc: Clarify Platform::accessibilityActive threading
 use [v2]
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <mCgzZDdYULQ8v8otVB0u3pKcye4ng7UwqTaVLbvBhMg=.b2160a26-3888-412f-acc4-123d00df3694@github.com>

> Changed the spec to require access only from the FX application thread.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1728/files
  - new: https://git.openjdk.org/jfx/pull/1728/files/4aa52a54..6a1a152e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1728/head:pull/1728

PR: https://git.openjdk.org/jfx/pull/1728

From jvos at openjdk.org  Tue Mar  4 21:07:47 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 4 Mar 2025 21:07:47 GMT
Subject: [jfx17u] RFR: 8350437: [GHA] Update gradle wrapper-validation action
 to v3
Message-ID: <BJTs31k46Q9N4ss7xMzcUx1PZ7rTaKjPflamLP-YW0U=.538fccd7-8065-4d82-b58a-dfd76340f62f@github.com>

Use latest action and gradle wrapper

-------------

Commit messages:
 - Backport 163bf6d42fde7de0454695311746964ff6bc1f49

Changes: https://git.openjdk.org/jfx17u/pull/226/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=226&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350437
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx17u/pull/226.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/226/head:pull/226

PR: https://git.openjdk.org/jfx17u/pull/226

From jpereda at openjdk.org  Tue Mar  4 21:07:47 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Tue, 4 Mar 2025 21:07:47 GMT
Subject: [jfx17u] RFR: 8350437: [GHA] Update gradle wrapper-validation
 action to v3
In-Reply-To: <BJTs31k46Q9N4ss7xMzcUx1PZ7rTaKjPflamLP-YW0U=.538fccd7-8065-4d82-b58a-dfd76340f62f@github.com>
References: <BJTs31k46Q9N4ss7xMzcUx1PZ7rTaKjPflamLP-YW0U=.538fccd7-8065-4d82-b58a-dfd76340f62f@github.com>
Message-ID: <QXL1R35k-CxxOqvk-M2vsXak30KCykZ9BTWmZ-Vwurw=.61c9e3b9-883d-44b9-87ac-50e7e03e26c0@github.com>

On Tue, 4 Mar 2025 21:02:19 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Use latest action and gradle wrapper

Marked as reviewed by jpereda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx17u/pull/226#pullrequestreview-2658992706

From kcr at openjdk.org  Tue Mar  4 21:27:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 4 Mar 2025 21:27:03 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
Message-ID: <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>

On Tue, 4 Mar 2025 19:34:11 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> @kevinrushforth I don't know, I would think it should be possible to create a property or property wrapper to make it thread-safe.  Just having a version with all its methods synchronized is probably sufficient.  If that saves a lot of complex logic in, what looks like, dozens of controls, then it seems like a far better solution to me.  Of course, that should only apply to special properties; I'm not suggesting making all properties synchronized -- although I think we could as, without contention (since they're supposed to be used from a single thread), it would be nearly free, and it would make all kinds of undefined behavior scenario's when used from multiple threads (by accident or otherwise) suddenly deterministic and debuggable.
>
> I think the problem is in the callbacks themselves, as they'd be on the wrong thread.  I vaguely remember experimenting with a system where you can provide an Executor for callbacks (like `Platform::runLater`) to mitigate this.

The listener callbacks will always be on the thread that mutates the property being listened to, so that isn't the problem. The problem in this case is that adding or removing a listener while another thread is modifying the property, which will iterate the list of listeners, is not thread-safe. Consider the following:


        final var prop = new SimpleBooleanProperty(false);

        // add listeners in a background thread
        var thr = new Thread(() -> {
            for (int i = 0; i < 10000; i++) {
                ChangeListener<Boolean> listener = (obs, o, n) -> {
                    if (!mainThread.equals(Thread.currentThread())) {
                        System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
                    }
                };
                prop.addListener(listener);
            }
        });
        thr.start();

        // Fire events in main thread
        for (int jj = 0; jj < 10000; jj++) {
            prop.set(!prop.get());
        }


The listeners all get called on the (correct) main thread, but continually adding listeners while the property is modified will lead to AIOOBE or NPE (the above example gets random NPEs when I run it).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980254928

From angorya at openjdk.org  Tue Mar  4 22:52:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 4 Mar 2025 22:52:02 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <FwCd3oWq9AdksbBai-Wht04Kfte0fGZHt2cgXkLmfrM=.91bd31b9-5ea8-4a3d-a3fe-0464b7c2a751@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

Looks good, and I don't see any regressions.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1723#pullrequestreview-2659278859

From jhendrikx at openjdk.org  Tue Mar  4 23:02:07 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 4 Mar 2025 23:02:07 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
 <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_
 7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
 <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>
Message-ID: <q7ZiCvLM_f1ZbSDnxcNzU3P-WsPJbJRJ7bm30uqxGEI=.fd0bb6e3-ba2c-4629-83d5-1570e3dab3d9@github.com>

On Tue, 4 Mar 2025 22:59:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> The listener callbacks will always be on the thread that mutates the property being listened to, so that isn't the problem. The problem in this case is that adding or removing a listener while another thread is modifying the property, which will iterate the list of listeners, is not thread-safe. Consider the following:
>> 
>> 
>>         final var prop = new SimpleBooleanProperty(false);
>> 
>>         // add listeners in a background thread
>>         var thr = new Thread(() -> {
>>             for (int i = 0; i < 10000; i++) {
>>                 ChangeListener<Boolean> listener = (obs, o, n) -> {
>>                     if (!mainThread.equals(Thread.currentThread())) {
>>                         System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
>>                     }
>>                 };
>>                 prop.addListener(listener);
>>             }
>>         });
>>         thr.start();
>> 
>>         // Fire events in main thread
>>         for (int jj = 0; jj < 10000; jj++) {
>>             prop.set(!prop.get());
>>         }
>> 
>> 
>> The listeners all get called on the (correct) main thread, but continually adding listeners while the property is modified will lead to AIOOBE or NPE (the above example gets random NPEs when I run it).
>
> Yes, but that's because there is no synchronization.  Here is a version that does do synchronization; I see no more exceptions (and it runs just as fast really):
> 
> 
> public class PropTest {
>   public static void main(String[] args) {
>     Thread mainThread = Thread.currentThread();
>     final var prop = new SimpleBooleanProperty(false) {
>       @Override
>       public synchronized void addListener(ChangeListener<? super Boolean> listener) {
>         super.addListener(listener);
>       }
> 
>       @Override
>       public synchronized void set(boolean newValue) {
>         super.set(newValue);
>       }
>     };
> 
>     // add listeners in a background thread
>     var thr = new Thread(() -> {
>         for (int i = 0; i < 1000000; i++) {
>             ChangeListener<Boolean> listener = (obs, o, n) -> {
>                 if (!mainThread.equals(Thread.currentThread())) {
>                     System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
>                 }
>             };
>             prop.addListener(listener);
>         }
>     });
>     thr.start();
> 
>     // Fire events in main thread
>     for (int jj = 0; jj < 1000000; jj++) {
>         prop.set(!prop.get());
>     }
>   }
> }

Of course for a generic solution, we could provide a wrapper for properties, or custom synchronized properties.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980382245

From jhendrikx at openjdk.org  Tue Mar  4 23:02:07 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 4 Mar 2025 23:02:07 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
 <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_
 7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
Message-ID: <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>

On Tue, 4 Mar 2025 21:24:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think the problem is in the callbacks themselves, as they'd be on the wrong thread.  I vaguely remember experimenting with a system where you can provide an Executor for callbacks (like `Platform::runLater`) to mitigate this.
>
> The listener callbacks will always be on the thread that mutates the property being listened to, so that isn't the problem. The problem in this case is that adding or removing a listener while another thread is modifying the property, which will iterate the list of listeners, is not thread-safe. Consider the following:
> 
> 
>         final var prop = new SimpleBooleanProperty(false);
> 
>         // add listeners in a background thread
>         var thr = new Thread(() -> {
>             for (int i = 0; i < 10000; i++) {
>                 ChangeListener<Boolean> listener = (obs, o, n) -> {
>                     if (!mainThread.equals(Thread.currentThread())) {
>                         System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
>                     }
>                 };
>                 prop.addListener(listener);
>             }
>         });
>         thr.start();
> 
>         // Fire events in main thread
>         for (int jj = 0; jj < 10000; jj++) {
>             prop.set(!prop.get());
>         }
> 
> 
> The listeners all get called on the (correct) main thread, but continually adding listeners while the property is modified will lead to AIOOBE or NPE (the above example gets random NPEs when I run it).

Yes, but that's because there is no synchronization.  Here is a version that does do synchronization; I see no more exceptions (and it runs just as fast really):


public class PropTest {
  public static void main(String[] args) {
    Thread mainThread = Thread.currentThread();
    final var prop = new SimpleBooleanProperty(false) {
      @Override
      public synchronized void addListener(ChangeListener<? super Boolean> listener) {
        super.addListener(listener);
      }

      @Override
      public synchronized void set(boolean newValue) {
        super.set(newValue);
      }
    };

    // add listeners in a background thread
    var thr = new Thread(() -> {
        for (int i = 0; i < 1000000; i++) {
            ChangeListener<Boolean> listener = (obs, o, n) -> {
                if (!mainThread.equals(Thread.currentThread())) {
                    System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
                }
            };
            prop.addListener(listener);
        }
    });
    thr.start();

    // Fire events in main thread
    for (int jj = 0; jj < 1000000; jj++) {
        prop.set(!prop.get());
    }
  }
}

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980380695

From kcr at openjdk.org  Wed Mar  5 00:29:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 00:29:01 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <q7ZiCvLM_f1ZbSDnxcNzU3P-WsPJbJRJ7bm30uqxGEI=.fd0bb6e3-ba2c-4629-83d5-1570e3dab3d9@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
 <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_
 7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
 <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>
 <q7ZiCvLM_f1ZbSDnxcNzU3P-WsPJbJRJ7bm30uqxGEI=.fd0bb6e3-ba2c-4629-83d5-1570e3dab3d9@github.com>
Message-ID: <1iTwzFMQh068eukEtZhx2KZhuICVD2vbQlQT11xf7vo=.9db1b753-07cf-4cdf-8bde-7fd6a0e14a76@github.com>

On Tue, 4 Mar 2025 23:00:01 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Yes, but that's because there is no synchronization.  Here is a version that does do synchronization; I see no more exceptions (and it runs just as fast really):
>> 
>> 
>> public class PropTest {
>>   public static void main(String[] args) {
>>     Thread mainThread = Thread.currentThread();
>>     final var prop = new SimpleBooleanProperty(false) {
>>       @Override
>>       public synchronized void addListener(ChangeListener<? super Boolean> listener) {
>>         super.addListener(listener);
>>       }
>> 
>>       @Override
>>       public synchronized void set(boolean newValue) {
>>         super.set(newValue);
>>       }
>>     };
>> 
>>     // add listeners in a background thread
>>     var thr = new Thread(() -> {
>>         for (int i = 0; i < 1000000; i++) {
>>             ChangeListener<Boolean> listener = (obs, o, n) -> {
>>                 if (!mainThread.equals(Thread.currentThread())) {
>>                     System.err.println("***** ERROR: listener called on wrong thread: " + Thread.currentThread());
>>                 }
>>             };
>>             prop.addListener(listener);
>>         }
>>     });
>>     thr.start();
>> 
>>     // Fire events in main thread
>>     for (int jj = 0; jj < 1000000; jj++) {
>>         prop.set(!prop.get());
>>     }
>>   }
>> }
>
> Of course for a generic solution, we could provide a wrapper for properties, or custom synchronized properties.

Yes, using a custom property, or a wrapper, would solve this particular synchronization problem, although that wouldn't solve all of the problems. 

We would then be left with the problem that if the accessibility change listener did fire -- which necessarily happens on the FX app thread -- while the object was being set up on a background thread, the listener might try to modify properties that are being touched on the background thread. This is just another case of a more general problem we already have with animation, and which Andy fixed by not starting animation in a few places unless and until we are on the FX app thread.

So I think the solution Andy has chosen of deferring adding the listener is better than trying to fix the accessibility property, followed by fixing the listeners that use it, to be thread-safe.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980469351

From kcr at openjdk.org  Wed Mar  5 00:30:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 00:30:57 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <8a-U0rUEAckOyWo1B_WPd84V8SWfBEvksseuwx7WlNc=.4fed9618-81b7-482c-8a8d-4489dd932552@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
 <inoKbcfV10oIpV5AgHa3dx4w-w3bmW6DupzyLkj9nZ4=.3207f71d-39ef-4f61-9a41-92db527382ef@github.com>
 <8a-U0rUEAckOyWo1B_WPd84V8SWfBEvksseuwx7WlNc=.4fed9618-81b7-482c-8a8d-4489dd932552@github.com>
Message-ID: <7Uj0oSawy6CL7aYcI3AcgVkB63r262z0Nf7WqGAxn90=.75a82079-140a-41f5-8ceb-1d5d80791f9a@github.com>

On Tue, 4 Mar 2025 20:39:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> `Robot::getPixelColor` can't return null (although I checked the docs and we don't specify one way or the other). It seems fine either way.
>
> what if the lambdas never run?

Then we have far bigger problems than this one test. The reason we use `runAndWait` instead of `runLater` is so we guarantee that the lambda has run before that method returns. It's guaranteed to do so.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980471260

From kevin.rushforth at oracle.com  Wed Mar  5 00:46:45 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 4 Mar 2025 16:46:45 -0800
Subject: JavaFX 24.0.1 will be closed for fixes on March 11th
Message-ID: <d8e9da3c-a2e9-42f1-ad10-806a3804c47b@oracle.com>

All,

If you have backports that you want to get into jfx24u for JavaFX 
24.0.1, please do so by Monday, March 10th. Note that approval from one 
of the project leads is needed as outlined in this message [1].

Starting Tuesday, March 11th, jfx24u will be open for JavaFX 24.0.2 fixes.

Thanks.

-- Kevin

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-January/051817.html


From kcr at openjdk.org  Wed Mar  5 00:47:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 00:47:12 GMT
Subject: [jfx24u] RFR: Merge jfx:jfx24
Message-ID: <0Jc9OmyyPxlbVBs9nedRI1tN5palTT9yJyfq9N3-9wQ=.efb67c01-3271-4b1f-a54a-32fd1d9b75c9@github.com>

Clean merge from `jfx:jfx24`.

-------------

Commit messages:
 - Merge remote-tracking branch 'jfx/jfx24' into merge-jfx-jfx24-to-master-2025-03-04
 - 8349472: Update copyright header for files modified in 2025

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jfx24u&pr=10&range=00.0
 - jfx:jfx24: https://webrevs.openjdk.org/?repo=jfx24u&pr=10&range=00.1

Changes: https://git.openjdk.org/jfx24u/pull/10/files
  Stats: 65 lines in 65 files changed: 0 ins; 0 del; 65 mod
  Patch: https://git.openjdk.org/jfx24u/pull/10.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/10/head:pull/10

PR: https://git.openjdk.org/jfx24u/pull/10

From kcr at openjdk.org  Wed Mar  5 01:05:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 01:05:57 GMT
Subject: [jfx24u] Integrated: Merge jfx:jfx24
In-Reply-To: <0Jc9OmyyPxlbVBs9nedRI1tN5palTT9yJyfq9N3-9wQ=.efb67c01-3271-4b1f-a54a-32fd1d9b75c9@github.com>
References: <0Jc9OmyyPxlbVBs9nedRI1tN5palTT9yJyfq9N3-9wQ=.efb67c01-3271-4b1f-a54a-32fd1d9b75c9@github.com>
Message-ID: <agnOib_x8IBkvpKmt1AKT-NrOVlSx-d2b7FsYwhR24Q=.bf099f5c-5642-4002-9732-dbd3b1a639c9@github.com>

On Wed, 5 Mar 2025 00:42:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge from `jfx:jfx24`.

This pull request has now been integrated.

Changeset: f6d4f114
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/f6d4f114cdb53791bdcb0cf501be3e029d6b149d
Stats:     65 lines in 65 files changed: 0 ins; 0 del; 65 mod

Merge

-------------

PR: https://git.openjdk.org/jfx24u/pull/10

From nlisker at openjdk.org  Wed Mar  5 03:08:05 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 5 Mar 2025 03:08:05 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v5]
In-Reply-To: <ms4JTLKN02L3oEAU9A6F8B0PIA1-KONVY_sjgCjNJdk=.31c20ecd-c547-41e7-8dff-1919ea9c06c9@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <a8QcT2WNcZbz4lLGkcAufiuuYRtV0hKlq9oTYLfhb3Y=.7213b233-b77b-4864-ad32-8d4021e886f6@github.com>
 <bnnntl1yRHwgN9ycirb2ExXwGXCGCY1yWT5NXjnY9tk=.e70cc523-15ab-4062-ba6f-aec9092574de@github.com>
 <ms4JTLKN02L3oEAU9A6F8B0PIA1-KONVY_sjgCjNJdk=.31c20ecd-c547-41e7-8dff-1919ea9c06c9@github.com>
Message-ID: <9ILstJxHvJ6bLYlXz9t_mnryDwu43jUt7FTS98mHGLU=.5e476c80-8375-48c8-bef0-55b577a40544@github.com>

On Thu, 20 Feb 2025 14:08:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > Z 0->1
> > A 0->1; set 2
> >   Z 1->2;
> >   A 1->2; no change
> >   B 0->2
> >   C 0->2; sets 3
> >     Z 2->3
> >     A 2->3; if A sets 2 we will get a SOE because of recursive changes; let's say A wants value>=2 and not ==2
> >     B 2->3
> >     C 2->3; no change
> >     D 0->3
> >   D ignores set->2 event since it got a more updated value (tracked by the progress value?)
> > B, C, D ignore set->1 event since they got a more updated value

> Apart from the nesting you have, this is exactly what this PR currently does. The problem with the nesting you have is that we can really only track one old value per nesting. If we need to track individual old values then we need to wrap each listener and give the wrapper a field with what value was sent last to it.

Yes, it does the same, except for the SOE I noted. If the way I do the nesting incurs a performance penalty, then it can be ignored since it has the same result. As for the SOE...

Edge cases of 2 listeners fighting: As noted from my example, I prefer an exception (doesn't need to be SOE), but it will be difficult to produce artificially. I don't think you can know if 2 listeners will converge on a value or diverge.

Edge case of listener changing value again: I agree.

Edge cases of addition and removal: I'm fine with this PR's behavior, but noted my surprise that a listener (on the same property) did not receive a value *before* it was removed. I agree that this is not critical.

> I think that this implementation operates well within the current specification (ie. it could be integrated without any documentation clarifications), but I'm open to specifying some behavior (as provided by JavaFX) explicitly so applications may rely on it more (if they aren't already).

I think that for now we shouldn't specify anything, but wait to see if problems crop up after this gets released into the wild.

> Is there anything that still needs to be discussed at this point? I think that you found some interesting edge cases, but as most involved registering and removing listener on the same property on which you already have a listener, I think that those are more hypothetical than cases we need to document or remain compatible with.

Not really, except for maybe the first edge case where your opinion differs from the current behavior. You also noted

> When it comes to value changes, you can only have it one way; either last wins and earlier listeners may be unaware of a value being reset, or first wins and later listeners may be unaware of a value being reset. Neither will be intuitive; given the way listeners are currently already used for "veto" style behavior, I think it would be far better to go for the "first wins" option, as anyone can always install a later listener breaking whatever you intended in the last-wins case.

which is also reasonable ("first wins").

---

I still have to review the tests and some of the implementation, but I'm willing to approve this PR at any time if you're eager to integrate it and have enough reviewers.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2699662293

From duke at openjdk.org  Wed Mar  5 06:00:58 2025
From: duke at openjdk.org (duke)
Date: Wed, 5 Mar 2025 06:00:58 GMT
Subject: Withdrawn: 8346281: [Windows] RenderScale doesn't update to HiDPI
 changes
In-Reply-To: <yIaijaemWMiEj42JpWnAXAL3UVKNBfULIqOicxOzgQM=.c57a19c6-e11e-4dce-90a3-407e9eb2c288@github.com>
References: <yIaijaemWMiEj42JpWnAXAL3UVKNBfULIqOicxOzgQM=.c57a19c6-e11e-4dce-90a3-407e9eb2c288@github.com>
Message-ID: <o9fZNEZHKB9s2IKRG_zX89XEwf0ynUbkv9SWh-C1oOg=.58452a85-dc51-4e87-80ca-c0f0330c1b30@github.com>

On Mon, 23 Dec 2024 10:51:39 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> This PR adds the missing native implementation for Windows `GlassWindow::HandleDPIEvent`, to notify the (Java) window when there is a DPI change event, which can happen when the user changes the resolution of the screen (via Settings -> System -> Display -> scale), while the JavaFX application is running.
> 
> When such `WM_DPICHANGED` event happens, `GlassWindow::HandleDPIEvent` notifies the (Java) window, which changes its platform scale via `Window::notifyScaleChanged`, and `GlassScreen::HandleDisplayChange();` is needed too, to update the platform scale of the screen where the window is at as well.
> 
> There are no tests added to this PR, since these would require manual intervention to change the display. In any case, the test case added to the [issue](https://bugs.openjdk.org/browse/JDK-8346281) runs fine now when the app runs on a given screen and the user changes its resolution. 
> 
> There is a follow-up issue after this PR, that might require a more complex fix, for the case where the user changes the resolution of a different screen that is placed before the one that has the application (as location coordinates of the latter depend on the former), because there is no `WM_DPICHANGED` event in this case.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx/pull/1668

From zjx001202 at gmail.com  Wed Mar  5 06:41:49 2025
From: zjx001202 at gmail.com (Glavo)
Date: Wed, 5 Mar 2025 14:41:49 +0800
Subject: Some issues with increasing the value of javafx.animation.pulse
Message-ID: <CAJL5A3=iQEKpOGn8=4AHAU4G-0M+Fh1u+ZsfiqFEbEM8c6DotQ@mail.gmail.com>

We tried setting javafx.animation.pulse to 120 in our JavaFX application.
After a few days of collecting feedback, we found the following issues

* Animation frame rate does not seem to be improved on HiDPI screens on
Windows.
* JavaFX applications prevent NVIDIA Advanced Optimus from automatically
selecting graphics cards when javafx.animation.pulse is set.

Glavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250305/a3a1b5ca/attachment.htm>

From jvos at openjdk.org  Wed Mar  5 06:55:15 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 06:55:15 GMT
Subject: [jfx17u] RFR: 8346228: Update GStreamer to 1.24.10
Message-ID: <VioBTWzJqR83SJDa0Hlrxl8-JKfSmtHWeApDHik3RL4=.449ce3d6-c6ba-475c-a953-633fece51d71@github.com>

Hi all,

This pull request contains a backport of commit 22035dec from the openjdk/jfx repository.

The commit being backported was authored by Alexander Matveev on 14 Jan 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 22035dec470756e03d254aa12c088876ae20497d

Changes: https://git.openjdk.org/jfx17u/pull/227/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=227&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346228
  Stats: 12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod
  Patch: https://git.openjdk.org/jfx17u/pull/227.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/227/head:pull/227

PR: https://git.openjdk.org/jfx17u/pull/227

From jvos at openjdk.org  Wed Mar  5 06:58:01 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 06:58:01 GMT
Subject: [jfx17u] Integrated: 8350437: [GHA] Update gradle wrapper-validation
 action to v3
In-Reply-To: <BJTs31k46Q9N4ss7xMzcUx1PZ7rTaKjPflamLP-YW0U=.538fccd7-8065-4d82-b58a-dfd76340f62f@github.com>
References: <BJTs31k46Q9N4ss7xMzcUx1PZ7rTaKjPflamLP-YW0U=.538fccd7-8065-4d82-b58a-dfd76340f62f@github.com>
Message-ID: <i6_JgWNCyeOI5B_5T83OyWj1EN-kaOTI8rSXquJk4u8=.6621fa21-f800-4047-a5d3-8ef574c05dfc@github.com>

On Tue, 4 Mar 2025 21:02:19 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Use latest action and gradle wrapper

This pull request has now been integrated.

Changeset: 1cacfdbb
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/1cacfdbb0fe19d4874d43f28223647e6b9287f99
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8350437: [GHA] Update gradle wrapper-validation action to v3

Reviewed-by: jpereda
Backport-of: 163bf6d42fde7de0454695311746964ff6bc1f49

-------------

PR: https://git.openjdk.org/jfx17u/pull/226

From duke at openjdk.org  Wed Mar  5 07:01:42 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 5 Mar 2025 07:01:42 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v4]
In-Reply-To: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
Message-ID: <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>

> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
> 
> Hence we are adding a system test now.
> 
> Test is written as 
> 1. Load html content in web view.
> 2. pick the color of mouse pointer.
> 3. Perform double click.
> 4. pick the color again.
>> expected bahaviour: colour picked in step 2 and 4 should not match.
> 
> Verification:
> The test passes with latest webkit source
> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.

Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:

  Addressed Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1719/files
  - new: https://git.openjdk.org/jfx/pull/1719/files/b4836243..d05cbf08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1719&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1719.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1719/head:pull/1719

PR: https://git.openjdk.org/jfx/pull/1719

From jvos at openjdk.org  Wed Mar  5 07:04:03 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 07:04:03 GMT
Subject: [jfx17u] Integrated: 8346228: Update GStreamer to 1.24.10
In-Reply-To: <VioBTWzJqR83SJDa0Hlrxl8-JKfSmtHWeApDHik3RL4=.449ce3d6-c6ba-475c-a953-633fece51d71@github.com>
References: <VioBTWzJqR83SJDa0Hlrxl8-JKfSmtHWeApDHik3RL4=.449ce3d6-c6ba-475c-a953-633fece51d71@github.com>
Message-ID: <s7-5nGAtH0PGbGQ30GEgFlxFjAErVeN305cksvaijkc=.b87f25c9-c40e-4dd4-ac73-8d6ddd9b3fdb@github.com>

On Wed, 5 Mar 2025 06:50:52 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 22035dec from the openjdk/jfx repository.
> 
> The commit being backported was authored by Alexander Matveev on 14 Jan 2025 and was reviewed by Joeri Sykora and Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: c03086d1
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/c03086d1b320e7a4fbf42a3a8b5b7968647d9206
Stats:     12196 lines in 105 files changed: 3855 ins; 7196 del; 1145 mod

8346228: Update GStreamer to 1.24.10
8346229: Update Glib to 2.82.4

Backport-of: 22035dec470756e03d254aa12c088876ae20497d

-------------

PR: https://git.openjdk.org/jfx17u/pull/227

From jvos at openjdk.org  Wed Mar  5 07:06:32 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 07:06:32 GMT
Subject: [jfx17u] RFR: 8323880: Caret rendered at wrong position in case of a
 click event on RTL text
Message-ID: <2TBflnfPH1l3HLTTCEYHbcauzJkoTt9egfZUEFtFqHg=.dbb68049-645f-4eda-8e99-d9f2c0bc9842@github.com>

Hi all,

This pull request contains a backport of commit [1fb56e33](https://github.com/openjdk/jfx/commit/1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.

The commit being backported was authored by Jay Bhaskar on 16 Feb 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.

Thanks!

-------------

Commit messages:
 - Backport 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3

Changes: https://git.openjdk.org/jfx17u/pull/228/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=228&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8323880
  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/228.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/228/head:pull/228

PR: https://git.openjdk.org/jfx17u/pull/228

From duke at openjdk.org  Wed Mar  5 07:09:02 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 5 Mar 2025 07:09:02 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <qZ8s6k8T9ET7H8JZONE9XhDKYk7bJJDv_8aiv8ACr_A=.d8c722a0-4d59-4d35-bd02-6ef485d046af@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <zFAaEFrk80okgpHtzMvfkOFIM3Owax575hU2KJ3qKGg=.3862d038-5cad-4153-8681-1712065a665f@github.com>
 <qZ8s6k8T9ET7H8JZONE9XhDKYk7bJJDv_8aiv8ACr_A=.d8c722a0-4d59-4d35-bd02-6ef485d046af@github.com>
Message-ID: <_hoVlhKeA1WboFJBzwrH-MwXItU9R9835JrJyNRUUbU=.eef1eda8-ac61-4078-b876-519c1dd4bb39@github.com>

On Wed, 5 Mar 2025 07:06:00 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 50:
>> 
>>> 48:     <body>&nbsp&nbsp&nbsp&nbsp some text</body>
>>> 49:     </html>
>>> 50:     """;
>> 
>> One more minor code style issue: lines 45-50 should be intended
>
> Done as per one suggestion on "https://docs.oracle.com/en/java/javase/18/text-blocks/index.html"

Removed the line "<head></head>" as this is empty.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980818872

From duke at openjdk.org  Wed Mar  5 07:09:02 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 5 Mar 2025 07:09:02 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <7Uj0oSawy6CL7aYcI3AcgVkB63r262z0Nf7WqGAxn90=.75a82079-140a-41f5-8ceb-1d5d80791f9a@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <WZbVpee23fZyuIb_AIbkgntbzI6INMHgMUQHNqTQ9_o=.479d752e-403b-43eb-82d2-3521c1d6642d@github.com>
 <inoKbcfV10oIpV5AgHa3dx4w-w3bmW6DupzyLkj9nZ4=.3207f71d-39ef-4f61-9a41-92db527382ef@github.com>
 <8a-U0rUEAckOyWo1B_WPd84V8SWfBEvksseuwx7WlNc=.4fed9618-81b7-482c-8a8d-4489dd932552@github.com>
 <7Uj0oSawy6CL7aYcI3AcgVkB63r262z0Nf7WqGAxn90=.75a82079-140a-41f5-8ceb-1d5d80791f9a@github.com>
Message-ID: <9mVElas2cUa0gQlkhbsAx-UVHpi4wizYGb1PNBFxlIo=.bf97f3e1-23e9-4091-a8cb-1735df732865@github.com>

On Wed, 5 Mar 2025 00:28:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> what if the lambdas never run?
>
> Then we have far bigger problems than this one test. The reason we use `runAndWait` instead of `runLater` is so we guarantee that the lambda has run before that method returns. It's guaranteed to do so.

Added volatile to the variables colorBefore and colorAfter.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980814766

From duke at openjdk.org  Wed Mar  5 07:09:03 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 5 Mar 2025 07:09:03 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v4]
In-Reply-To: <fbUU0YFOvGyzf2c4n9n5PpBvIJx8iLeZkDntkWdsEaQ=.71579fe5-f6ee-4bf3-a480-a2b83c4ac439@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <8PtPXD8hTVpzl0XixxqhNiN1rDeyWp9hBvbcikFd2bI=.ec693954-976e-47dd-8256-37c2bafa6886@github.com>
 <7_S-ofCWiMT4jMMpBgmtfLcRazXxFLbi6B4hLkEUQx0=.93ee212e-b612-4d5b-8de1-29925c6207c2@github.com>
 <fbUU0YFOvGyzf2c4n9n5PpBvIJx8iLeZkDntkWdsEaQ=.71579fe5-f6ee-4bf3-a480-a2b83c4ac439@github.com>
Message-ID: <IBNGpsnzKBuNfYP7uXBRt-pbk8Ggs6DnOXgVhiI-n8w=.b9e1e79e-8276-489a-9b27-cd2208fa254d@github.com>

On Tue, 4 Mar 2025 15:38:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> We are not getting the text area from web view. This point is used to simulate the mouse click.
>
> so they are arbitrary, and will work for every font size?
> 
> (The default font size varies depending on the platform and other circumstances, see `PrismFontFactory::getSystemFontSize()` - though I am not sure if the default font size is picked up by the `WebView`.

Tested in font size 1 and 5 separately. In both case it passed. For this test case, set font size 2 for test purpose only.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980813140

From duke at openjdk.org  Wed Mar  5 07:09:01 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Wed, 5 Mar 2025 07:09:01 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v3]
In-Reply-To: <zFAaEFrk80okgpHtzMvfkOFIM3Owax575hU2KJ3qKGg=.3862d038-5cad-4153-8681-1712065a665f@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <-UwzQU9Lk3ph1EH-H4UYgF1ZhyETiYBg1do0PEs_IO8=.2a9308b2-a0b5-4923-82e7-6773a22f0c12@github.com>
 <zFAaEFrk80okgpHtzMvfkOFIM3Owax575hU2KJ3qKGg=.3862d038-5cad-4153-8681-1712065a665f@github.com>
Message-ID: <qZ8s6k8T9ET7H8JZONE9XhDKYk7bJJDv_8aiv8ACr_A=.d8c722a0-4d59-4d35-bd02-6ef485d046af@github.com>

On Tue, 4 Mar 2025 12:14:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Gopal Pattnaik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Addressed Review comments
>>  - Addressed Review comments
>
> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 42:
> 
>> 40: import test.util.Util;
>> 41: 
>> 42: public class TextSelectionTest extends RobotTestBase{
> 
> Minor: please add a space before the `{`

Done.

> tests/system/src/test/java/test/robot/javafx/web/TextSelectionTest.java line 50:
> 
>> 48:     <body>&nbsp&nbsp&nbsp&nbsp some text</body>
>> 49:     </html>
>> 50:     """;
> 
> One more minor code style issue: lines 45-50 should be intended

Done as per one suggestion on "https://docs.oracle.com/en/java/javase/18/text-blocks/index.html"

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980816617
PR Review Comment: https://git.openjdk.org/jfx/pull/1719#discussion_r1980817935

From jvos at openjdk.org  Wed Mar  5 07:29:13 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 07:29:13 GMT
Subject: [jfx17u] Integrated: 8323880: Caret rendered at wrong position in case
 of a click event on RTL text
In-Reply-To: <2TBflnfPH1l3HLTTCEYHbcauzJkoTt9egfZUEFtFqHg=.dbb68049-645f-4eda-8e99-d9f2c0bc9842@github.com>
References: <2TBflnfPH1l3HLTTCEYHbcauzJkoTt9egfZUEFtFqHg=.dbb68049-645f-4eda-8e99-d9f2c0bc9842@github.com>
Message-ID: <qEn-XWF1lJSCmpPfH-UokD9wRRyYRSVLeqtpQPLe3eU=.233380ad-95b0-4bed-9168-5345929dabae@github.com>

On Wed, 5 Mar 2025 07:00:00 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fb56e33](https://github.com/openjdk/jfx/commit/1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3) from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
> 
> The commit being backported was authored by Jay Bhaskar on 16 Feb 2024 and was reviewed by Kevin Rushforth and Hima Bindu Meda.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 99f04d10
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/99f04d10f78b78abc0129db81073545c1528268c
Stats:     12 lines in 1 file changed: 12 ins; 0 del; 0 mod

8323880: Caret rendered at wrong position in case of a click event on RTL text

Backport-of: 1fb56e333bc65860cc1abeebd1cbb01cd8b8e5f3

-------------

PR: https://git.openjdk.org/jfx17u/pull/228

From jvos at openjdk.org  Wed Mar  5 07:46:31 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 07:46:31 GMT
Subject: [jfx17u] RFR: 8315873: [GHA] Update checkout and cache action to use
 v4
Message-ID: <Pb6FxJ5lmVBn9DAxI5htao1cm3IoVLfgbe0WSXLcn88=.59e4082f-a8fc-42c8-950a-57e89e2a4d0b@github.com>

mainly clean backport of https://github.com/openjdk/jfx/commit/6ec588c5635964769b354bce37e68d7a6c00985a (JDK-8315873)

Reason for being non-clean:
* we already applied 8350437
* we don't have aarch64-mac
* we don't have TEST_ONLY in build.gradle

-------------

Commit messages:
 - Backport 6ec588c5635964769b354bce37e68d7a6c00985a

Changes: https://git.openjdk.org/jfx17u/pull/229/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=229&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315873
  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx17u/pull/229.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/229/head:pull/229

PR: https://git.openjdk.org/jfx17u/pull/229

From jpereda at openjdk.org  Wed Mar  5 08:21:57 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 5 Mar 2025 08:21:57 GMT
Subject: [jfx17u] RFR: 8315873: [GHA] Update checkout and cache action to
 use v4
In-Reply-To: <Pb6FxJ5lmVBn9DAxI5htao1cm3IoVLfgbe0WSXLcn88=.59e4082f-a8fc-42c8-950a-57e89e2a4d0b@github.com>
References: <Pb6FxJ5lmVBn9DAxI5htao1cm3IoVLfgbe0WSXLcn88=.59e4082f-a8fc-42c8-950a-57e89e2a4d0b@github.com>
Message-ID: <9Gd4UgjAmMSE1eC5PYrepdoEdBUpVqVQ2whJDYdOdj8=.50c81d3c-2fc6-4a8d-b239-41894c2a9543@github.com>

On Wed, 5 Mar 2025 07:41:50 GMT, Johan Vos <jvos at openjdk.org> wrote:

> mainly clean backport of https://github.com/openjdk/jfx/commit/6ec588c5635964769b354bce37e68d7a6c00985a (JDK-8315873)
> 
> Reason for being non-clean:
> * we already applied 8350437
> * we don't have aarch64-mac
> * we don't have TEST_ONLY in build.gradle

Marked as reviewed by jpereda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx17u/pull/229#pullrequestreview-2660299235

From jvos at openjdk.org  Wed Mar  5 08:29:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 08:29:08 GMT
Subject: [jfx17u] RFR: 8340322: Update WebKit to 620.1
Message-ID: <PRNoiyezpcj275Y4w5QkqS5QdxeCnpo0VT2f_DLyRf8=.11d4d162-935f-4130-9217-cc9ba8b1c6bd@github.com>

Almost clean backport of JDK-8340322
Manually changed:

* build.gradle minor change
* modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
* modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

-------------

Commit messages:
 - Backport 1e6915738d654e6cf7a547e47b8b020117db6bc3

Changes: https://git.openjdk.org/jfx17u/pull/230/files
  Webrev: Webrev is not available because diff is too large
  Issue: https://bugs.openjdk.org/browse/JDK-8340322
  Stats: 773683 lines in 8157 files changed: 644448 ins; 72180 del; 57055 mod
  Patch: https://git.openjdk.org/jfx17u/pull/230.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/230/head:pull/230

PR: https://git.openjdk.org/jfx17u/pull/230

From jpereda at openjdk.org  Wed Mar  5 08:32:02 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Wed, 5 Mar 2025 08:32:02 GMT
Subject: [jfx17u] RFR: 8340322: Update WebKit to 620.1
In-Reply-To: <PRNoiyezpcj275Y4w5QkqS5QdxeCnpo0VT2f_DLyRf8=.11d4d162-935f-4130-9217-cc9ba8b1c6bd@github.com>
References: <PRNoiyezpcj275Y4w5QkqS5QdxeCnpo0VT2f_DLyRf8=.11d4d162-935f-4130-9217-cc9ba8b1c6bd@github.com>
Message-ID: <G2ZKmvZey066K2ELqjLDm_3rZnigoBrJwIy_K4CZNqE=.4d185879-4a9a-43b3-8d55-038ff71aed4d@github.com>

On Wed, 5 Mar 2025 08:17:16 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8340322
> Manually changed:
> 
> * build.gradle minor change
> * modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
> * modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

Marked as reviewed by jpereda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx17u/pull/230#pullrequestreview-2660323313

From jvos at openjdk.org  Wed Mar  5 08:32:59 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 08:32:59 GMT
Subject: [jfx17u] Integrated: 8315873: [GHA] Update checkout and cache action
 to use v4
In-Reply-To: <Pb6FxJ5lmVBn9DAxI5htao1cm3IoVLfgbe0WSXLcn88=.59e4082f-a8fc-42c8-950a-57e89e2a4d0b@github.com>
References: <Pb6FxJ5lmVBn9DAxI5htao1cm3IoVLfgbe0WSXLcn88=.59e4082f-a8fc-42c8-950a-57e89e2a4d0b@github.com>
Message-ID: <KNjC0dXS3xy6ZAa2qfvuMFMJ6JG658Nw_dfigNhhOw4=.5c9d925d-778f-42d3-b265-42ecb284169b@github.com>

On Wed, 5 Mar 2025 07:41:50 GMT, Johan Vos <jvos at openjdk.org> wrote:

> mainly clean backport of https://github.com/openjdk/jfx/commit/6ec588c5635964769b354bce37e68d7a6c00985a (JDK-8315873)
> 
> Reason for being non-clean:
> * we already applied 8350437
> * we don't have aarch64-mac
> * we don't have TEST_ONLY in build.gradle

This pull request has now been integrated.

Changeset: 15c0a968
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/15c0a9687329c7067a9e43f71c34ad52d6ba530f
Stats:     7 lines in 1 file changed: 0 ins; 0 del; 7 mod

8315873: [GHA] Update checkout and cache action to use v4

Reviewed-by: jpereda
Backport-of: 6ec588c5635964769b354bce37e68d7a6c00985a

-------------

PR: https://git.openjdk.org/jfx17u/pull/229

From jvos at openjdk.org  Wed Mar  5 08:41:02 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 08:41:02 GMT
Subject: [jfx17u] Integrated: 8340322: Update WebKit to 620.1
In-Reply-To: <PRNoiyezpcj275Y4w5QkqS5QdxeCnpo0VT2f_DLyRf8=.11d4d162-935f-4130-9217-cc9ba8b1c6bd@github.com>
References: <PRNoiyezpcj275Y4w5QkqS5QdxeCnpo0VT2f_DLyRf8=.11d4d162-935f-4130-9217-cc9ba8b1c6bd@github.com>
Message-ID: <hc_b-1tvyKbJR2wH8Bql5QmxZD9DJ0-Tv7C5G-3VwZM=.e460f1c5-d3d5-4286-bd2e-b343bc8b6336@github.com>

On Wed, 5 Mar 2025 08:17:16 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Almost clean backport of JDK-8340322
> Manually changed:
> 
> * build.gradle minor change
> * modules/javafx.web/src/main/native/Source/WebCore/html/parser/HTMLElementStack.cpp because JDK-8344899 is not backported
> * modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java because JDK-8339515 is not backported

This pull request has now been integrated.

Changeset: 4bdd3209
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/4bdd3209be401abf78d85679eae7cfccd5def763
Stats:     773683 lines in 8157 files changed: 644448 ins; 72180 del; 57055 mod

8340322: Update WebKit to 620.1

Reviewed-by: jpereda
Backport-of: 1e6915738d654e6cf7a547e47b8b020117db6bc3

-------------

PR: https://git.openjdk.org/jfx17u/pull/230

From jvos at openjdk.org  Wed Mar  5 08:49:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 08:49:08 GMT
Subject: [jfx17u] Integrated: 8349891: Not implemented function should have
 printf
Message-ID: <Iyfbxxg7O4NgTW9M_pI5qSm9shIORWSM3guEYoPCQr0=.0bfa63b2-1403-43ee-8ec9-ebb66e601996@github.com>

Hi all,

This pull request contains a backport of commit 065548d0 from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 18 Feb 2025 and was reviewed by Kevin Rushforth.

Thanks!

-------------

Commit messages:
 - Backport 065548d09dd4909137343e7e9eb2d25a336a34dd

Changes: https://git.openjdk.org/jfx17u/pull/231/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=231&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349891
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx17u/pull/231.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/231/head:pull/231

PR: https://git.openjdk.org/jfx17u/pull/231

From jvos at openjdk.org  Wed Mar  5 08:49:08 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 08:49:08 GMT
Subject: [jfx17u] Integrated: 8349891: Not implemented function should have
 printf
In-Reply-To: <Iyfbxxg7O4NgTW9M_pI5qSm9shIORWSM3guEYoPCQr0=.0bfa63b2-1403-43ee-8ec9-ebb66e601996@github.com>
References: <Iyfbxxg7O4NgTW9M_pI5qSm9shIORWSM3guEYoPCQr0=.0bfa63b2-1403-43ee-8ec9-ebb66e601996@github.com>
Message-ID: <A0afeGciIqK93z4PsIZ3N2I2DJwPscaUtO9z8K4GuU0=.00a985f7-c9bb-4b00-bf84-b0f688afd922@github.com>

On Wed, 5 Mar 2025 08:42:31 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit 065548d0 from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 18 Feb 2025 and was reviewed by Kevin Rushforth.
> 
> Thanks!

This pull request has now been integrated.

Changeset: cb77869b
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/cb77869b4b12b46c1087114186ee6ccbeadc6f5e
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8349891: Not implemented function should have printf

Backport-of: 065548d09dd4909137343e7e9eb2d25a336a34dd

-------------

PR: https://git.openjdk.org/jfx17u/pull/231

From jvos at openjdk.org  Wed Mar  5 09:25:18 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 09:25:18 GMT
Subject: [jfx17u] Integrated: 8349924: Additional WebKit 620.1 fixes from
 WebKitGTK 2.46.6
Message-ID: <aUMFS6m9SQZe6Gc2FsqZVOj9vakfxCbCgERiO-7YPh0=.89ded630-ecf4-479b-b157-ecf9fcdb4b62@github.com>

Hi all,

This pull request contains a backport of commit f38ab33b from the openjdk/jfx repository.

The commit being backported was authored by Jay Bhaskar on 25 Feb 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.

Thanks!

-------------

Commit messages:
 - Backport f38ab33b296de7b0bf5b306e4803de8c686e2a83

Changes: https://git.openjdk.org/jfx17u/pull/232/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx17u&pr=232&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349924
  Stats: 2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod
  Patch: https://git.openjdk.org/jfx17u/pull/232.diff
  Fetch: git fetch https://git.openjdk.org/jfx17u.git pull/232/head:pull/232

PR: https://git.openjdk.org/jfx17u/pull/232

From jvos at openjdk.org  Wed Mar  5 09:25:18 2025
From: jvos at openjdk.org (Johan Vos)
Date: Wed, 5 Mar 2025 09:25:18 GMT
Subject: [jfx17u] Integrated: 8349924: Additional WebKit 620.1 fixes from
 WebKitGTK 2.46.6
In-Reply-To: <aUMFS6m9SQZe6Gc2FsqZVOj9vakfxCbCgERiO-7YPh0=.89ded630-ecf4-479b-b157-ecf9fcdb4b62@github.com>
References: <aUMFS6m9SQZe6Gc2FsqZVOj9vakfxCbCgERiO-7YPh0=.89ded630-ecf4-479b-b157-ecf9fcdb4b62@github.com>
Message-ID: <w-beZe4bxLcbMI5hsKWPdXxE4xA72rnMjO0mdGyF3qA=.2658db18-8378-475a-b5c0-ea3b7f913630@github.com>

On Wed, 5 Mar 2025 09:19:01 GMT, Johan Vos <jvos at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit f38ab33b from the openjdk/jfx repository.
> 
> The commit being backported was authored by Jay Bhaskar on 25 Feb 2025 and was reviewed by Kevin Rushforth and Joeri Sykora.
> 
> Thanks!

This pull request has now been integrated.

Changeset: caaf3e33
Author:    Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.org/jfx17u/commit/caaf3e33d71801231923ed64f94dd8fc1196151a
Stats:     2933 lines in 108 files changed: 1269 ins; 1316 del; 348 mod

8349924: Additional WebKit 620.1 fixes from WebKitGTK 2.46.6

Backport-of: f38ab33b296de7b0bf5b306e4803de8c686e2a83

-------------

PR: https://git.openjdk.org/jfx17u/pull/232

From kcr at openjdk.org  Wed Mar  5 12:23:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 12:23:59 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v4]
In-Reply-To: <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
Message-ID: <HH6hZmbhL6urA-BKmSeE82ZQYouGar7aXomfn8jsfJo=.a2d660a5-20b3-4670-a9cc-29a89f45eea0@github.com>

On Wed, 5 Mar 2025 07:01:42 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

Looks good.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1719#pullrequestreview-2660948197

From jhendrikx at openjdk.org  Wed Mar  5 14:50:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 14:50:11 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v5]
In-Reply-To: <9ILstJxHvJ6bLYlXz9t_mnryDwu43jUt7FTS98mHGLU=.5e476c80-8375-48c8-bef0-55b577a40544@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <a8QcT2WNcZbz4lLGkcAufiuuYRtV0hKlq9oTYLfhb3Y=.7213b233-b77b-4864-ad32-8d4021e886f6@github.com>
 <bnnntl1yRHwgN9ycirb2ExXwGXCGCY1yWT5NXjnY9tk=.e70cc523-15ab-4062-ba6f-aec9092574de@github.com>
 <ms4JTLKN02L3oEAU9A6F8B0PIA1-KONVY_sjgCjNJdk=.31c20ecd-c547-41e7-8dff-1919ea9c06c9@github.com>
 <9ILstJxHvJ6bLYlXz9t_mnryDwu43jUt7FTS98mHGLU=.5e476c80-8375-48c8-bef0-55b577a40544@github.com>
Message-ID: <k9ToWO9MTiPSmjrXyaoq5iJ8x_mlkoYBrlT98OeW1yw=.ada0e31e-8a05-48b7-b2ac-774540cc8a10@github.com>

On Wed, 5 Mar 2025 03:05:25 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Not really, except for maybe the first edge case where your opinion differs from the current behavior.

You mean the one where I said: "this PR should probably not silently allow this but instead throw an exception" ?

I think that's worth fixing, and I will look into it.  An exception would be good here to inform the user of a problem; it not only would be closer to the old behavior, but it also prevents a silent modification of the value from occurring.  Perhaps something like `IllegalStateException("non-converging value detected in value modifying listeners") :)

I'm not sure this will be easy to add, but I'll have a go.

> I still have to review the tests and some of the implementation, but I'm willing to approve this PR at any time if you're eager to integrate it and have enough reviewers.

I just didn't want the discussion to die out since we seem to be close to getting this issue resolved.  Kevin has expressed he will want to review it as well, so it is not like I would integrate it before he has time to do that.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2701158047

From john.hendrikx at gmail.com  Wed Mar  5 15:09:36 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 5 Mar 2025 16:09:36 +0100
Subject: Some issues with increasing the value of javafx.animation.pulse
In-Reply-To: <CAJL5A3=iQEKpOGn8=4AHAU4G-0M+Fh1u+ZsfiqFEbEM8c6DotQ@mail.gmail.com>
References: <CAJL5A3=iQEKpOGn8=4AHAU4G-0M+Fh1u+ZsfiqFEbEM8c6DotQ@mail.gmail.com>
Message-ID: <84292190-9fac-4703-aa71-9f507a72535d@gmail.com>

Hi Glavo,

On which platform is this?? On Windows I really don't expect that
setting pulse higher will do much (I posted this a few days ago on this
list in response to your earlier inquiry).? It may trigger more frames
to be rendered, but their animation times will not use correct values
resulting in it just rendering duplicate frames or frames with only
slight differences (and not the expected 1/120 difference).

On the Windows platform I think we need to do some more work to get
animations >60 Hz -- specifically, the FX thread needs to be scheduled
reliably at intervals lower than 15 ms, which is non-trivial on Windows.

As for the NVIDIA problem; I doubt that setting "javafx.animation.pulse"
can have any effect on this. You may want to look further as to why this
problem occurs.

--John

On 05/03/2025 07:41, Glavo wrote:
> We tried setting javafx.animation.pulse to 120 in our JavaFX application.
> After a few days of collecting feedback, we found the following issues
>
> *?Animation frame rate does not seem to be improved on HiDPI screens
> on Windows.
> *?JavaFX applications prevent NVIDIA Advanced Optimus from
> automatically selecting graphics cards when javafx.animation.pulse is set.
>
> Glavo

From angorya at openjdk.org  Wed Mar  5 15:36:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 15:36:06 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v4]
In-Reply-To: <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
Message-ID: <8Pj6MEHFobjcuoFyR8zXdDCqF1XP_dI1kGXrdvtCOk4=.841256f0-2718-408d-9e9d-78fa61325ce7@github.com>

On Wed, 5 Mar 2025 07:01:42 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

lgtm, thank you for addressing the comments.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1719#pullrequestreview-2661538430

From angorya at openjdk.org  Wed Mar  5 15:50:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 15:50:08 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <1iTwzFMQh068eukEtZhx2KZhuICVD2vbQlQT11xf7vo=.9db1b753-07cf-4cdf-8bde-7fd6a0e14a76@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
 <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_
 7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
 <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>
 <q7ZiCvLM_f1ZbSDnxcNzU3P-WsPJbJRJ7bm30uqxGEI=.fd0bb6e3-ba2c-4629-83d5-1570e3dab3d9@github.com>
 <1iTwzFMQh068eukEtZhx2KZhuICVD2vbQlQT11xf7vo=.9db1b753-07cf-4cdf-8bde-7fd6a0e14a76@github.com>
Message-ID: <qntDKjItdQ5wO54c_VjxVVIefl9DYbBvuvDyqbTMGM0=.3c958831-792e-4cd1-a91e-6262418ef613@github.com>

On Wed, 5 Mar 2025 00:26:12 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Of course for a generic solution, we could provide a wrapper for properties, or custom synchronized properties.
>
> Yes, using a custom property, or a wrapper, would solve this particular synchronization problem, although that wouldn't solve all of the problems. 
> 
> We would then be left with the problem that if the accessibility change listener did fire -- which necessarily happens on the FX app thread -- while the object was being set up on a background thread, the listener might try to modify properties that are being touched on the background thread. This is just another case of a more general problem we already have with animation, and which Andy fixed by not starting animation in a few places unless and until we are on the FX app thread.
> 
> So I think the solution Andy has chosen of deferring adding the listener is better than trying to fix the accessibility property, followed by fixing the listeners that use it, to be thread-safe.

Thank you, @kevinrushforth .

Getting back to the rule of allowing Node construction from a background thread but not "use", should we consider enforcing the thread access rules for global and static objects (like Platform properties)?

In other words, constructing objects that might modify internal properties is ok, but trying to access shared objects is not?

(maybe it's time to move the discussion out of this PR into the mailing list perhaps?)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1981692877

From angorya at openjdk.org  Wed Mar  5 15:54:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 15:54:49 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v6]
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <mt_kO4AVu51QSTxBHVOQ2P6-V28gjRnaVRa52MjLf5g=.ace534cf-3778-40c3-83d6-a10dfff7e8d7@github.com>

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - atomic boolean
 - Merge branch 'master' into 8342565.stub.text.layout
 - cleanup
 - better test
 - cleanup
 - ... and 14 more: https://git.openjdk.org/jfx/compare/7e0c73d0...3650989a

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1667/files
  - new: https://git.openjdk.org/jfx/pull/1667/files/d29bebdf..3650989a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=04-05

  Stats: 1221 lines in 12 files changed: 189 ins; 937 del; 95 mod
  Patch: https://git.openjdk.org/jfx/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667

PR: https://git.openjdk.org/jfx/pull/1667

From angorya at openjdk.org  Wed Mar  5 15:54:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 15:54:51 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v5]
In-Reply-To: <awTSF3JoWcpPPqcoyFfYCsyeZgUlvmHHX2G-NLt6Xlk=.a7fb3312-cd87-4dcb-8cb9-b829431bd572@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <awTSF3JoWcpPPqcoyFfYCsyeZgUlvmHHX2G-NLt6Xlk=.a7fb3312-cd87-4dcb-8cb9-b829431bd572@github.com>
Message-ID: <ZQ7-DWbGkY9wyDs8OXC-ryVHOG-LX4R_PuhyNX9RaE0=.81dca431-02bf-403c-9179-6c8924ad497c@github.com>

On Wed, 26 Feb 2025 22:00:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - atomic boolean
>  - Merge branch 'master' into 8342565.stub.text.layout
>  - cleanup
>  - better test
>  - cleanup
>  - more magic
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/75e5d8b0...d29bebdf

please review

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2701352486

From zjx001202 at gmail.com  Wed Mar  5 16:09:31 2025
From: zjx001202 at gmail.com (Glavo)
Date: Thu, 6 Mar 2025 00:09:31 +0800
Subject: Some issues with increasing the value of javafx.animation.pulse
In-Reply-To: <84292190-9fac-4703-aa71-9f507a72535d@gmail.com>
References: <CAJL5A3=iQEKpOGn8=4AHAU4G-0M+Fh1u+ZsfiqFEbEM8c6DotQ@mail.gmail.com>
 <84292190-9fac-4703-aa71-9f507a72535d@gmail.com>
Message-ID: <CAJL5A3=N95xNK2=eicJ7GpR2Y058fL1vUMcFr+6aLGMeKZKJFA@mail.gmail.com>

Hi John,

The above feedback is all for Windows, and we have not tested on other
platforms yet.

On Windows I really don't expect that
> setting pulse higher will do much (I posted this a few days ago on this
> list in response to your earlier inquiry)


In fact, setting the pulse higher does have a noticeable effect on
non-HiDPI screens.
On my 1440p at 120hz monitor it works perfectly and I can clearly feel that it
no longer has the same stuttering as it does at 60fps.
But when DPI scaling is used, the 60fps stutter reappears and the frame
rate of the JavaFX application is significantly lower than that of other
windows.

As for the NVIDIA problem; I doubt that setting "javafx.animation.pulse"
> can have any effect on this. You may want to look further as to why this
> problem occurs.


This feedback comes from our users. Specifically, we added the following
code to the application main method:

System.getProperties().putIfAbsent("javafx.animation.pulse", "120");


So users can override the value by adding JVM arguments.

We told the user to try adding the JVM
argument `-Djavafx.animation.pulse=60`, and the user later told us that
this solved his problem.
So we think this is the result of adjusting this property.

Glavo


On Wed, Mar 5, 2025 at 11:09?PM John Hendrikx <john.hendrikx at gmail.com>
wrote:

> Hi Glavo,
>
> On which platform is this?  On Windows I really don't expect that
> setting pulse higher will do much (I posted this a few days ago on this
> list in response to your earlier inquiry).  It may trigger more frames
> to be rendered, but their animation times will not use correct values
> resulting in it just rendering duplicate frames or frames with only
> slight differences (and not the expected 1/120 difference).
>
> On the Windows platform I think we need to do some more work to get
> animations >60 Hz -- specifically, the FX thread needs to be scheduled
> reliably at intervals lower than 15 ms, which is non-trivial on Windows.
>
> As for the NVIDIA problem; I doubt that setting "javafx.animation.pulse"
> can have any effect on this. You may want to look further as to why this
> problem occurs.
>
> --John
>
> On 05/03/2025 07:41, Glavo wrote:
> > We tried setting javafx.animation.pulse to 120 in our JavaFX application.
> > After a few days of collecting feedback, we found the following issues
> >
> > * Animation frame rate does not seem to be improved on HiDPI screens
> > on Windows.
> > * JavaFX applications prevent NVIDIA Advanced Optimus from
> > automatically selecting graphics cards when javafx.animation.pulse is
> set.
> >
> > Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250306/585d926d/attachment.htm>

From kizune at openjdk.org  Wed Mar  5 16:32:12 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 16:32:12 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v9]
In-Reply-To: <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
Message-ID: <NR5KLB4CO80fL88HxkinKx1jywmXVNJ8C5Pk8SqwJBk=.7dc2588b-c512-4cec-9484-bd8014f0d897@github.com>

On Tue, 4 Mar 2025 19:32:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Marked as reviewed by kizune (Author).

I finished testing of the last iteration and i do not see any regressions in the accessibility on Mac or Windows - seems to be working fine on both platforms.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1697#pullrequestreview-2661708743
PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2701457628

From kizune at openjdk.org  Wed Mar  5 16:50:58 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 16:50:58 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <6SgIXUhWU5LrOJdw9_zpIdV4nojDvqX_oxXmks_7LvI=.70e6b188-858c-4909-aa0f-674d1754ac5e@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
 <R-_y7qMgzUkG615LV9B8W8YHWc1RxxjWf2La1mNel4E=.a65ea895-d122-41f4-bb37-5aa504317479@github.com>
 <6SgIXUhWU5LrOJdw9_zpIdV4nojDvqX_oxXmks_7LvI=.70e6b188-858c-4909-aa0f-674d1754ac5e@github.com>
Message-ID: <3AM5WAzrGcOKq3WDbMkac2RWOf6H-JZLHAYr6-UNa7E=.b6493a4e-78dc-492c-aeef-afe28884fe01@github.com>

On Mon, 3 Mar 2025 16:54:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Also, for Spinner, it says "Stepper", is this expected?

On macOS the control we call Spinner is called Stepper, there's no Spinner.

>From macOS UI guide: "A stepper is a two-segment control that people use to increase or decrease an incremental value."

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2701505972

From angorya at openjdk.org  Wed Mar  5 16:50:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 16:50:59 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <3AM5WAzrGcOKq3WDbMkac2RWOf6H-JZLHAYr6-UNa7E=.b6493a4e-78dc-492c-aeef-afe28884fe01@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
 <R-_y7qMgzUkG615LV9B8W8YHWc1RxxjWf2La1mNel4E=.a65ea895-d122-41f4-bb37-5aa504317479@github.com>
 <6SgIXUhWU5LrOJdw9_zpIdV4nojDvqX_oxXmks_7LvI=.70e6b188-858c-4909-aa0f-674d1754ac5e@github.com>
 <3AM5WAzrGcOKq3WDbMkac2RWOf6H-JZLHAYr6-UNa7E=.b6493a4e-78dc-492c-aeef-afe28884fe01@github.com>
Message-ID: <zAUsDaLmcTOK2KFVTNWpOTqe-PJB-MLHZlD62yGJo-g=.f01dc720-4b0f-4963-a317-415728853b71@github.com>

On Wed, 5 Mar 2025 16:47:06 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Spinner is called Stepper

yep, that's what I suspected.  thanks!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2701509394

From kizune at openjdk.org  Wed Mar  5 17:12:36 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 17:12:36 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v8]
In-Reply-To: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
Message-ID: <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>

> Create implementation for Slider and Stepper accessibility protocols.
> Fix mapping.
> Fix performAction parameter type in declaration.

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate code make accessibilityLabel explicitly call accessibilityTitle and add coment explaining why.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1226/files
  - new: https://git.openjdk.org/jfx/pull/1226/files/09f68099..1ae393ac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1226&range=06-07

  Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1226.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1226/head:pull/1226

PR: https://git.openjdk.org/jfx/pull/1226

From john.hendrikx at gmail.com  Wed Mar  5 17:17:12 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 5 Mar 2025 18:17:12 +0100
Subject: Some issues with increasing the value of javafx.animation.pulse
In-Reply-To: <CAJL5A3=N95xNK2=eicJ7GpR2Y058fL1vUMcFr+6aLGMeKZKJFA@mail.gmail.com>
References: <CAJL5A3=iQEKpOGn8=4AHAU4G-0M+Fh1u+ZsfiqFEbEM8c6DotQ@mail.gmail.com>
 <84292190-9fac-4703-aa71-9f507a72535d@gmail.com>
 <CAJL5A3=N95xNK2=eicJ7GpR2Y058fL1vUMcFr+6aLGMeKZKJFA@mail.gmail.com>
Message-ID: <2d316be1-6ef0-4de1-98c3-295b539d8062@gmail.com>

Hi Glavo,

On 05/03/2025 17:09, Glavo wrote:
> Hi John,
>
> The above feedback is all for Windows, and we have not tested on other
> platforms yet.

Thanks for clarifying. I may be able to help a bit better then as I have
a similar setup.

>
>     On Windows I really don't expect that
>     setting pulse higher will do much (I posted this a few days ago on
>     this
>     list in response to your earlier inquiry)
>
>
> In fact, setting?the pulse higher?does have a noticeable effect on
> non-HiDPI screens.
> On my 1440p at 120hz monitor it works perfectly and I can clearly feel
> that it no longer has the same stuttering as it does at 60fps.

Could you check the clock resolution on your system when it works
smoothly, you can use this tool:
https://learn.microsoft.com/en-us/sysinternals/downloads/clockres

This is unfortunately a global setting, and will greatly impact the
thread scheduling on Windows systems.? It defaults to 15.625 ms, but
when something like a game or video is running, it may have been changed
to a lower value; the value may differ for example on a fresh reboot,
but be changed to a lower value when certain apps run. I expect that
when it is set to the default, FX will not be able to do smooth 120 Hz
displays as it relies on its thread being scheduled on time (but the
default is only just sufficient for 60 Hz).?

> But when DPI scaling is used, the 60fps stutter reappears and the
> frame rate of the JavaFX application is significantly lower than that
> of other windows.

Could this be simply that more work needs to be done and JavaFX is not
keeping up on a high DPI screen?? I've noticed that when I run my app
full screen on 1920x1200 vs 3840x2160 (one at 100%, the other at 150%)
that the second runs somewhat slower, but it has to display 4x the
pixels... if you suspect display scaling is the issue, you could
temporarily set the display to 100% and try again.

>
>     As for the NVIDIA problem; I doubt that setting
>     "javafx.animation.pulse"
>     can have any effect on this. You may want to look further as to
>     why this
>     problem occurs.
>
>
> This feedback comes from our users. Specifically, we added the
> following code to the application main method:
>
>     System.getProperties().putIfAbsent("javafx.animation.pulse", "120");
>
>
> So users can override the?value by adding JVM arguments.
>
> We told the user to try adding the JVM
> argument?`-Djavafx.animation.pulse=60`, and the user later told us
> that this solved his problem.
> So we think this is the result of adjusting this property.

Yes, I understand; there is just nothing in the code that would explain
this; it's not like this value is used to change any hardware settings,
it is just a value that is used to increment a long value that keeps
track of the frame time we need to send to animation code.?

--John

>
> Glavo
> ?
>
> On Wed, Mar 5, 2025 at 11:09?PM John Hendrikx
> <john.hendrikx at gmail.com> wrote:
>
>     Hi Glavo,
>
>     On which platform is this?? On Windows I really don't expect that
>     setting pulse higher will do much (I posted this a few days ago on
>     this
>     list in response to your earlier inquiry).? It may trigger more frames
>     to be rendered, but their animation times will not use correct values
>     resulting in it just rendering duplicate frames or frames with only
>     slight differences (and not the expected 1/120 difference).
>
>     On the Windows platform I think we need to do some more work to get
>     animations >60 Hz -- specifically, the FX thread needs to be scheduled
>     reliably at intervals lower than 15 ms, which is non-trivial on
>     Windows.
>
>     As for the NVIDIA problem; I doubt that setting
>     "javafx.animation.pulse"
>     can have any effect on this. You may want to look further as to
>     why this
>     problem occurs.
>
>     --John
>
>     On 05/03/2025 07:41, Glavo wrote:
>     > We tried setting javafx.animation.pulse to 120 in our JavaFX
>     application.
>     > After a few days of collecting feedback, we found the following
>     issues
>     >
>     > *?Animation frame rate does not seem to be improved on HiDPI screens
>     > on Windows.
>     > *?JavaFX applications prevent NVIDIA Advanced Optimus from
>     > automatically selecting graphics cards when
>     javafx.animation.pulse is set.
>     >
>     > Glavo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250305/77e91cbd/attachment-0001.htm>

From kizune at openjdk.org  Wed Mar  5 17:20:02 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 5 Mar 2025 17:20:02 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v7]
In-Reply-To: <zAUsDaLmcTOK2KFVTNWpOTqe-PJB-MLHZlD62yGJo-g=.f01dc720-4b0f-4963-a317-415728853b71@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <Y6JRS0V5N6qTpiXQETY9vZxRT_4CcO4XlvEoyV0w6CM=.627d25dd-c21f-4c6a-8251-0d48987b902a@github.com>
 <R-_y7qMgzUkG615LV9B8W8YHWc1RxxjWf2La1mNel4E=.a65ea895-d122-41f4-bb37-5aa504317479@github.com>
 <6SgIXUhWU5LrOJdw9_zpIdV4nojDvqX_oxXmks_7LvI=.70e6b188-858c-4909-aa0f-674d1754ac5e@github.com>
 <3AM5WAzrGcOKq3WDbMkac2RWOf6H-JZLHAYr6-UNa7E=.b6493a4e-78dc-492c-aeef-afe28884fe01@github.com>
 <zAUsDaLmcTOK2KFVTNWpOTqe-PJB-MLHZlD62yGJo-g=.f01dc720-4b0f-4963-a317-415728853b71@github.com>
Message-ID: <revDQerUNd1gpz-4A6WTUSgfXqLcCplnPkaLuTCo2J8=.e29a927f-9720-46f5-8588-f2c75c7ce524@github.com>

On Wed, 5 Mar 2025 16:48:22 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> so the remaining question is whether it should announce "percent" of the slider position or the actual value?

Unfortunately we do not have any control on that. There is no way to tell VoiceOver if it is percent or the raw value - VO deducts it based on its own logic. The only way to customize the VO heuristics is to override accessibilityValueDescription function and return string for VO but then we would need to decode for ourselves how do we convert the value plus it will be our responsibility to do localization of this string if needed.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2701584916

From angorya at openjdk.org  Wed Mar  5 17:32:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 17:32:05 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v8]
In-Reply-To: <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
Message-ID: <0gQjMc4YriyfNcbVZgxzE-ncNVilA_2cMVUwW9C0cB4=.8769d4bb-a6a8-4151-893d-8e7c25823012@github.com>

On Wed, 5 Mar 2025 17:12:36 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Create implementation for Slider and Stepper accessibility protocols.
>> Fix mapping.
>> Fix performAction parameter type in declaration.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate code make accessibilityLabel explicitly call accessibilityTitle and add coment explaining why.

yep, you are right: we don't want to deal with interpreting and l10n.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1226#pullrequestreview-2661870350

From angorya at openjdk.org  Wed Mar  5 17:36:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 17:36:01 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v9]
In-Reply-To: <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
Message-ID: <HQ2_BungaeHhXxKsouhvsU4fa4KqYuw4chxW2oo2pUU=.b3680642-b93d-407e-b0bf-ed4dd468cebe@github.com>

On Tue, 4 Mar 2025 19:32:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Root Cause:
>> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
>> 
>> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
>> 
>> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
>> 
>> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
>> 
>> With this change, it is safe to create and populate charts with data in a background thread.
>> 
>> ---
>> 
>> ## NOTES
>> 
>> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
>> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
>> 
>> ## Note to the Reviewers
>> 
>> To avoid merge conflicts, the preferred order of integrations:
>> 
>> #1697 
>> #1713 
>> #1717
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

@hjohn thank you for help with `Subscription`.  Do you have any other comments?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2701621607

From kcr at openjdk.org  Wed Mar  5 17:39:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 5 Mar 2025 17:39:06 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v6]
In-Reply-To: <qntDKjItdQ5wO54c_VjxVVIefl9DYbBvuvDyqbTMGM0=.3c958831-792e-4cd1-a91e-6262418ef613@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <iyrblJeMGTXcPkBFRv5bRSU5r65VFQwvJG6Td8t6nwQ=.a15e6f18-2caa-448e-86d8-26f3723fee56@github.com>
 <aJqKIUCHgmCqu_CKPNAw3ZfPVZp6qOhQ5J3gDYVLI0w=.a94f512e-017e-4b52-b2c9-0b70baab3daf@github.com>
 <XfWqePxKj1aGyjc6k4mgMKHZcIPuu4xGBi7ZNeeTdMo=.453e578a-ef1d-453e-8ad7-a7e2ef5f3628@github.com>
 <en_kDuCqIYUdnatg_4LLxH3ivMVgn5MprmkL7q0QJIQ=.951bdc1b-4139-4719-9446-d3dea56f0c03@github.com>
 <ELLT0b9CSMT72r5m66-8UvMNeduPD6SfeOPm2L1ysPs=.8fd32fae-e620-467f-84e9-cd1a7d5ffd9d@github.com>
 <zsM5xkB3Vwzlj094hPkzcOAH16grK6m6ioXQJul8DoY=.0e7d794b-cb51-41aa-b14c-03b339f5631c@github.com>
 <kvfZ-06aXJVMYX6j6ydfThb2YnQOBWaPzdpBDJia7ug=.4f917076-cd4e-4870-b0ae-01eb9c0648a3@github.com>
 <SNeq9FrXSzYgi6aB_VqKWl_kfhFI1SwQ2xEijYXZvoQ=.fed2e80d-f441-4a5d-b91f-da859b393d0d@github.com>
 <eLp0_1wFqvZBcOFi-5L4MX3cLvE8FjVA1JbGhKk8e_8=.46b00ffd-85b9-40fe-83ab-c88da164c574@github.com>
 <QGnJNy2oEDQRCiakxqFA-ScJq7L2DAm5aI_
 7GrU7YY8=.63e5a5fc-20b2-411e-961d-6cdd77930b94@github.com>
 <6QzWJSQIPou3Ydo9qFNWFtzfmqYhTAxR6dAGmVk7KRc=.aac99b70-1065-44d2-9180-18f40bbeb14e@github.com>
 <q7ZiCvLM_f1ZbSDnxcNzU3P-WsPJbJRJ7bm30uqxGEI=.fd0bb6e3-ba2c-4629-83d5-1570e3dab3d9@github.com>
 <1iTwzFMQh068eukEtZhx2KZhuICVD2vbQlQT11xf7vo=.9db1b753-07cf-4cdf-8bde-7fd6a0e14a76@github.com>
 <qntDKjItdQ5wO54c_VjxVVIefl9DYbBvuvDyqbTMGM0=.3c958831-792e-4cd1-a91e-6262418ef613@github.com>
Message-ID: <HKm5pZ-uFvWjVCEnNMEricAedW88PDkC1655psN4SFw=.f394ef5a-04fb-4bd9-aed1-4ced6714df81@github.com>

On Wed, 5 Mar 2025 15:47:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, using a custom property, or a wrapper, would solve this particular synchronization problem, although that wouldn't solve all of the problems. 
>> 
>> We would then be left with the problem that if the accessibility change listener did fire -- which necessarily happens on the FX app thread -- while the object was being set up on a background thread, the listener might try to modify properties that are being touched on the background thread. This is just another case of a more general problem we already have with animation, and which Andy fixed by not starting animation in a few places unless and until we are on the FX app thread.
>> 
>> So I think the solution Andy has chosen of deferring adding the listener is better than trying to fix the accessibility property, followed by fixing the listeners that use it, to be thread-safe.
>
> Thank you, @kevinrushforth .
> 
> Getting back to the rule of allowing Node construction from a background thread but not "use", should we consider enforcing the thread access rules for global and static objects (like Platform properties)?
> 
> In other words, constructing objects that might modify internal properties is ok, but trying to access shared objects is not?
> 
> (maybe it's time to move the discussion out of this PR into the mailing list perhaps?)

Enforcing the threading restriction when using properties is a larger conversation. If we want to have it, I agree it should be on the mailing list.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1981874992

From jhendrikx at openjdk.org  Wed Mar  5 18:06:26 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 18:06:26 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v6]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Throw StackOverflowError if non-converging listener changes are detected

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/7affce77..85a4d34b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=04-05

  Stats: 181 lines in 2 files changed: 173 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From arapte at openjdk.org  Wed Mar  5 18:07:10 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Wed, 5 Mar 2025 18:07:10 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v8]
In-Reply-To: <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
Message-ID: <sGQrT0lo_6ydh86RoIhGRE8uucA_qMLB4H1HRgq69e0=.39b5938f-27c8-440d-856c-d3722354f94d@github.com>

On Wed, 5 Mar 2025 17:12:36 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Create implementation for Slider and Stepper accessibility protocols.
>> Fix mapping.
>> Fix performAction parameter type in declaration.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate code make accessibilityLabel explicitly call accessibilityTitle and add coment explaining why.

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1226#pullrequestreview-2661970870

From jhendrikx at openjdk.org  Wed Mar  5 18:09:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 18:09:06 GMT
Subject: RFR: 8349091: Charts: exception initializing in a background
 thread [v9]
In-Reply-To: <HQ2_BungaeHhXxKsouhvsU4fa4KqYuw4chxW2oo2pUU=.b3680642-b93d-407e-b0bf-ed4dd468cebe@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
 <FpQyg79w5dBQu4lsUxWOXiMxWiOqaSx9lO9W2kpsR5w=.d639358d-04fb-47e2-9dd5-cd211719ffdc@github.com>
 <HQ2_BungaeHhXxKsouhvsU4fa4KqYuw4chxW2oo2pUU=.b3680642-b93d-407e-b0bf-ed4dd468cebe@github.com>
Message-ID: <c4-UiQN-1w8qQar7nqPcziBtkhRqR74np6jdPKxkGkI=.5fe9afe6-d18a-477d-8bbb-b3175fb07036@github.com>

On Wed, 5 Mar 2025 17:33:01 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> @hjohn thank you for help with `Subscription`. Do you have any other comments?

No, but admittedly I did not look beyond the subscription issue.  I think Kevin and Alexander have got you covered on this one :)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1697#issuecomment-2701696645

From angorya at openjdk.org  Wed Mar  5 18:17:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 18:17:14 GMT
Subject: Integrated: 8349091: Charts: exception initializing in a background
 thread
In-Reply-To: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
References: <42ZFSi9OH6UvoVswgrOrXdoWbPjKD8JVDY3lN4TveNQ=.c2bf66e7-8d61-4735-968f-fb9ce1bced14@github.com>
Message-ID: <-2mKq7DF55fzTbmiYend2_WOc6AVXbxY9uxTo56nw7k=.2a718cf2-4201-4b86-85f6-f1d00023c456@github.com>

On Thu, 6 Feb 2025 19:26:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Root Cause:
> (Multiple) properties are getting bound to the global `Platform.accessibilityActive` property. Binding (and I say, accessing) of properties is not thread-safe.
> 
> I also changed the design a bit.  Originally, every symbol in a chart had its `focusTraversableProperty` bound to `Platform.accessibilityActive` in order to enable the accessibility navigation across the chart data points.  This is rather inefficient, as the property has to manage (thousands?) of listeners.
> 
> Instead, a single boolean property is added to each chart, with a listener added to it which iterates over data symbols to toggle the `focusTraversableProperty` directly.
> 
> The exact moment when the new property gets bound is also important, and has to happen in the FX application thread.
> 
> With this change, it is safe to create and populate charts with data in a background thread.
> 
> ---
> 
> ## NOTES
> 
> 1. It looks like the `Platform.accessibilityActive` property never transitions back to false  after it transitioned to true.  Some say it is because there is no mechanism in the platform to get notified which cannot possibly be true.
> 2. The javadoc for `Platform.accessibilityActiveProperty()` method stipulates that "_This method may be called from any thread_" which is patently not true as the current implementation is simply not thread-safe.
> 
> ## Note to the Reviewers
> 
> To avoid merge conflicts, the preferred order of integrations:
> 
> #1697 
> #1713 
> #1717

This pull request has now been integrated.

Changeset: fc770fb9
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/fc770fb96bdd6804c4b7633a62cbb2fe0a50345f
Stats:     316 lines in 11 files changed: 176 ins; 101 del; 39 mod

8349091: Charts: exception initializing in a background thread

Reviewed-by: kizune, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1697

From angorya at openjdk.org  Wed Mar  5 18:19:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 18:19:53 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
Message-ID: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>

> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
 - spelling
 - use system menu
 - cleanup
 - possible fix
 - test

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1727/files
  - new: https://git.openjdk.org/jfx/pull/1727/files/97aafcb9..69a52e64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1727&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1727&range=00-01

  Stats: 1488 lines in 19 files changed: 325 ins; 1034 del; 129 mod
  Patch: https://git.openjdk.org/jfx/pull/1727.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1727/head:pull/1727

PR: https://git.openjdk.org/jfx/pull/1727

From angorya at openjdk.org  Wed Mar  5 18:20:51 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 18:20:51 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
Message-ID: <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>

> - enforced fx application thread
> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
> - clarified `ComboBoxBase::show`
> - added a headful test `TestThreadingRestrictions`

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'origin/master' into 8350048.enforce
 - review comments
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8350048.enforce
 - fixed node init test
 - all tests
 - initial test

-------------

Changes: https://git.openjdk.org/jfx/pull/1717/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=04
  Stats: 479 lines in 13 files changed: 424 ins; 28 del; 27 mod
  Patch: https://git.openjdk.org/jfx/pull/1717.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717

PR: https://git.openjdk.org/jfx/pull/1717

From jhendrikx at openjdk.org  Wed Mar  5 18:27:29 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 18:27:29 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v7]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <Ig7k1z_zJJt-KSrXaPA7H6fgt5qBtFuGR85q75rdAn8=.80dd0781-58c5-4be7-a846-7d62aaef308c@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix docs

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/85a4d34b..8e198cdb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From jhendrikx at openjdk.org  Wed Mar  5 18:27:29 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 18:27:29 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v6]
In-Reply-To: <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>
Message-ID: <l1uWSvWmM_jadJCH47Z47knfJFDbdarway6ckcKyfIg=.79b00f7f-bbf3-406d-8d3a-94548f71e612@github.com>

On Wed, 5 Mar 2025 18:06:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
>> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
>> 
>> # About nested changes
>> 
>> Nested changes are simply changes...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw StackOverflowError if non-converging listener changes are detected

I've added code that will (sometimes manually, sometimes automatically) throw a `StackOverflowError` when problems with non-converging listener changes are detected.  I'm open to doing this differently, but have opted for `StackOverflowError` for two reasons:

1. ExpressionHelper would throw this (although not by choice)
2. Any "normal" exception is currently only logged as an exception thrown by the listener and so may disappear in the noise

Now, I'm not entirely sure this is the best decision, so I'm fine to changing this to a warning.  Note though that if I change it to a warning, then one (or more) listeners may be unaware that a value they set was reset (but the warning would prompt the developer to investigate).  I guess it is similar to the warning that FX emits when a property could not be reset when errors occur during binding.

Note that the non-convergence detection logic is pretty smart, as the test case where multiple listeners are trying to agree upon a value that is divisible by 3, 5, 7 and 11 still works fine; however, there may be cases that are detected as a problem too soon (especially if listeners only do their changes after X number of calls, or only if the call number is even or something weird like that).

Some of these cases may not have resulted in a stack overflow with `ExpressionHelper` (although with such tricks you can make the stack arbitrarily deep and then still "resolve" the issue before actually running out of stack).  However, the detection logic now in place does not have the luxury of just seeing if the problem resolves itself. This is because there is no actual call to the listeners involved to check if they aren't changing their behavior as the only way to do an actual call would be to call it with an old value that is equal to its new value, which we would rather not see (if we change our mind on this, then the detection logic can be removed and we can just enjoy **real** `StackOverflowError`s).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2701718806

From duke at openjdk.org  Wed Mar  5 18:27:30 2025
From: duke at openjdk.org (danielpeintner)
Date: Wed, 5 Mar 2025 18:27:30 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v6]
In-Reply-To: <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>
Message-ID: <GEP_pcgpBCFN91NfUjUpPSuqNP92pJEL3ZRLggYyGpQ=.f4574546-a8ec-426a-b7dc-710ceaf891fe@github.com>

On Wed, 5 Mar 2025 18:06:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
>> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
>> 
>> # About nested changes
>> 
>> Nested changes are simply changes...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw StackOverflowError if non-converging listener changes are detected

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 69:

> 67:      * been notified in higher level loops, while deeper nesting levels
> 68:      * communicate to higher level loops whether a nested notification
> 69:      * actually occurred if if it completed normally or was aborted early.<p>

Suggestion:

     * actually occurred if it completed normally or was aborted early.<p>

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1981930914

From jhendrikx at openjdk.org  Wed Mar  5 18:27:30 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 5 Mar 2025 18:27:30 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v6]
In-Reply-To: <GEP_pcgpBCFN91NfUjUpPSuqNP92pJEL3ZRLggYyGpQ=.f4574546-a8ec-426a-b7dc-710ceaf891fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <XuvB8mccEdk8DknqKpuu5-pAUqgGZoBduxvPRk6bUto=.e458478e-87d2-4a37-8133-f92a71e56aa2@github.com>
 <GEP_pcgpBCFN91NfUjUpPSuqNP92pJEL3ZRLggYyGpQ=.f4574546-a8ec-426a-b7dc-710ceaf891fe@github.com>
Message-ID: <nRNy_7m4FAaTvTZyhFXJabdG1qXnDsyg7SxRtdkRxvM=.18a78cee-7c65-4fa7-bce5-45dfa33c0ebd@github.com>

On Wed, 5 Mar 2025 18:16:11 GMT, danielpeintner <duke at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw StackOverflowError if non-converging listener changes are detected
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 69:
> 
>> 67:      * been notified in higher level loops, while deeper nesting levels
>> 68:      * communicate to higher level loops whether a nested notification
>> 69:      * actually occurred if if it completed normally or was aborted early.<p>
> 
> Suggestion:
> 
>      * actually occurred if it completed normally or was aborted early.<p>

Thanks, fixed :)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1981936512

From angorya at openjdk.org  Wed Mar  5 19:41:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 19:41:47 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType constructor
Message-ID: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>

- synchronized `EventType::register()` method
- simplified internal constructor which is only used for `EventType.ROOT`

There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.

There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.

-------------

Commit messages:
 - test
 - synchronized

Changes: https://git.openjdk.org/jfx/pull/1729/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351038
  Stats: 82 lines in 2 files changed: 64 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1729.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1729/head:pull/1729

PR: https://git.openjdk.org/jfx/pull/1729

From angorya at openjdk.org  Wed Mar  5 21:18:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 5 Mar 2025 21:18:39 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - 25 25
 - Merge branch 'master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge branch 'master' into ag.text.layout.api
 - segments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd

-------------

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=17
  Stats: 1515 lines in 14 files changed: 1439 ins; 21 del; 55 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From duke at openjdk.org  Thu Mar  6 01:50:06 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 01:50:06 GMT
Subject: RFR: 8313556: Create implementation of NSAccessibilitySlider
 protocol [v8]
In-Reply-To: <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
 <ATsMwHHn6kArNT125w0Yf2azMKmRt21ItBYjCpClcEk=.84aaae61-c7bd-4648-8f59-88d7c312fc0f@github.com>
Message-ID: <Ap7EUhiyC_rP1s7-VujAxlPtrIhBfC8aZuFqNqY9arc=.048ad5da-e2d5-4a46-96fd-2e335e9d80ab@github.com>

On Wed, 5 Mar 2025 17:12:36 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Create implementation for Slider and Stepper accessibility protocols.
>> Fix mapping.
>> Fix performAction parameter type in declaration.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove duplicate code make accessibilityLabel explicitly call accessibilityTitle and add coment explaining why.

@azuev-java 
Your change (at version 1ae393acced9cd1625cff4234292762ac7911024) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1226#issuecomment-2702514391

From nlisker at openjdk.org  Thu Mar  6 02:54:58 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 6 Mar 2025 02:54:58 GMT
Subject: RFR: 8345261: Refactor the Dimension2D classes
In-Reply-To: <iJCSkvxMB5WSi1mjvHGpP67jEAFSLFZ_9L_QOkV3NjI=.7df4dc22-1576-4d9b-84bd-36fa8f65ca6a@github.com>
References: <YrGqPSWSFSNx2H-1ZfkyrTILFMExj6q-_sfWlhzI-hQ=.782d35d8-01b7-417b-ae17-d824812b5c7e@github.com>
 <Rt92Wxj9XVUXRZOSks5Uy_MvwwSw5OuYK-LCQzBgrLs=.bbca62b8-357f-447c-bf94-1f840d1384ee@github.com>
 <rrtZ8shl0ADz9CffDZqVWY4HfJXN4Mpj81agPYmje3U=.86ab9fc8-e06f-4255-9fb6-5c89f8ea51c1@github.com>
 <iJCSkvxMB5WSi1mjvHGpP67jEAFSLFZ_9L_QOkV3NjI=.7df4dc22-1576-4d9b-84bd-36fa8f65ca6a@github.com>
Message-ID: <EsaI-tupLcyE2osFlpfw8b7Mp3fswUqWP3wGkYOPJNw=.e74ed77f-ce94-41ca-8a80-b37de907bd10@github.com>

On Mon, 2 Dec 2024 14:34:08 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose.
>
>> would you object to making Dimension an inner class of Rectangle?
> 
> I am fine with it.

> > Thanks @azvegint. If the `int`-based dimensions are coupled with `com.sun.javafx.geom.Rectangle` (and from the code, that's the only place they are used at), would you object to making `Dimension` an inner class of `Rectangle`? The `float`-based dimensions are used in other 2D shapes, so are more general purpose.
> 
> In my opinion, inner classes are justified when the implementations are coupled, or when one thing only makes sense in the context of another thing. That doesn't seem to be the case here: `Dimension` is neither used in `Rectangle`, nor are their implementations coupled.
> 
> What this suggests to me is that either `Dimension` should remain its own top-level class, or if it is not useful there, be moved to where it _is_ used instead.

The int-based Dimension is only used *by* `Rectangle` even if in another class. I can couple their implementations by adding a `Rectangle#asDimension2D`, and this will be the only instantiation of this class. Note that there's already a constructor `Dimension2Di(Rectangle rect)` that instantiates only via the enclosing class.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2702651232

From nlisker at openjdk.org  Thu Mar  6 03:12:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Thu, 6 Mar 2025 03:12:01 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v7]
In-Reply-To: <Ig7k1z_zJJt-KSrXaPA7H6fgt5qBtFuGR85q75rdAn8=.80dd0781-58c5-4be7-a846-7d62aaef308c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <Ig7k1z_zJJt-KSrXaPA7H6fgt5qBtFuGR85q75rdAn8=.80dd0781-58c5-4be7-a846-7d62aaef308c@github.com>
Message-ID: <SbNFK7H0iMTptmSxQivz3gLzuw4vsFt8V__n2hNSHS8=.7369f8e1-58b5-4318-89cb-5259a6a7ac80@github.com>

On Wed, 5 Mar 2025 18:27:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
>> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
>> 
>> # About nested changes
>> 
>> Nested changes are simply changes...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix docs

I tested the new convergence check. If listener A and listener B fight over a value, it works, but if I add after then listener C that just prints what it sees without changing the value, it completes without an error.

Is it not possible to let the SOE be thrown naturally (by infinite recursion)?

> Note that the non-convergence detection logic is pretty smart, as the test case where multiple listeners are trying to agree upon a value that is divisible by 3, 5, 7 and 11 still works fine

And what about non-integer values, like custom objects or strings?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2702676397

From duke at openjdk.org  Thu Mar  6 05:38:03 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Mar 2025 05:38:03 GMT
Subject: RFR: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1 [v4]
In-Reply-To: <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
 <zz80ONZyQrNrnIeCRTs4wzyNXvTVzN_jX3rRJt8w0os=.a2351df5-a676-4e43-a983-7aa8140cdcf8@github.com>
Message-ID: <-lVvwgfA3v2wPSpYjY4bwANfR-pbYVuS_Tyddou6_ws=.7316e47c-849b-43a2-88fd-857be32307ef@github.com>

On Wed, 5 Mar 2025 07:01:42 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

>> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
>> 
>> Hence we are adding a system test now.
>> 
>> Test is written as 
>> 1. Load html content in web view.
>> 2. pick the color of mouse pointer.
>> 3. Perform double click.
>> 4. pick the color again.
>>> expected bahaviour: colour picked in step 2 and 4 should not match.
>> 
>> Verification:
>> The test passes with latest webkit source
>> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.
>
> Gopal Pattnaik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed Review comments

@Gopalora 
Your change (at version d05cbf0817ac03754290a83c78be269d7967641b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1719#issuecomment-2702860351

From duke at openjdk.org  Thu Mar  6 05:43:07 2025
From: duke at openjdk.org (Gopal Pattnaik)
Date: Thu, 6 Mar 2025 05:43:07 GMT
Subject: Integrated: 8327478: Add System test to verify TextSelection issue for
 webkit-617.1
In-Reply-To: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
References: <f8FZzKNkjij8gsO24t8EBYxTd37iU4j_saIMia6KSic=.3e0128f3-1fdc-4525-9e43-f2cb692b50b8@github.com>
Message-ID: <Gns9ocLu4jxzfxsvgaCHw1fCV8hjNLKNKcn7d_Qrvac=.a8ad70ff-30c6-4153-9d50-0f38efceed9e@github.com>

On Fri, 21 Feb 2025 06:59:52 GMT, Gopal Pattnaik <duke at openjdk.org> wrote:

> There was no test included with the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989),
> 
> Hence we are adding a system test now.
> 
> Test is written as 
> 1. Load html content in web view.
> 2. pick the color of mouse pointer.
> 3. Perform double click.
> 4. pick the color again.
>> expected bahaviour: colour picked in step 2 and 4 should not match.
> 
> Verification:
> The test passes with latest webkit source
> Also verified that test fails when the fix for [JDK-8326989](https://bugs.openjdk.org/browse/JDK-8326989) is reverted.

This pull request has now been integrated.

Changeset: 0a20fefa
Author:    Gopal Pattnaik <gopal.pattnaik at oracle.com>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0a20fefad44487499a8a634623e658073a054f02
Stats:     104 lines in 2 files changed: 104 ins; 0 del; 0 mod

8327478: Add System test to verify TextSelection issue for webkit-617.1

Reviewed-by: kcr, angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1719

From jhendrikx at openjdk.org  Thu Mar  6 08:55:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 08:55:06 GMT
Subject: RFR: 8345261: Refactor the Dimension2D classes
In-Reply-To: <EsaI-tupLcyE2osFlpfw8b7Mp3fswUqWP3wGkYOPJNw=.e74ed77f-ce94-41ca-8a80-b37de907bd10@github.com>
References: <YrGqPSWSFSNx2H-1ZfkyrTILFMExj6q-_sfWlhzI-hQ=.782d35d8-01b7-417b-ae17-d824812b5c7e@github.com>
 <Rt92Wxj9XVUXRZOSks5Uy_MvwwSw5OuYK-LCQzBgrLs=.bbca62b8-357f-447c-bf94-1f840d1384ee@github.com>
 <rrtZ8shl0ADz9CffDZqVWY4HfJXN4Mpj81agPYmje3U=.86ab9fc8-e06f-4255-9fb6-5c89f8ea51c1@github.com>
 <iJCSkvxMB5WSi1mjvHGpP67jEAFSLFZ_9L_QOkV3NjI=.7df4dc22-1576-4d9b-84bd-36fa8f65ca6a@github.com>
 <EsaI-tupLcyE2osFlpfw8b7Mp3fswUqWP3wGkYOPJNw=.e74ed77f-ce94-41ca-8a80-b37de907bd10@github.com>
Message-ID: <zGCLlkBdEUrxfhRWa0HkKxdWYSSVZkhmcxK5OHrZqN4=.f482f0e8-6905-4be7-ac69-092a32159839@github.com>

On Thu, 6 Mar 2025 02:50:33 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> The int-based Dimension is only used by Rectangle even if in another class

I've taken another look.  Rectangle is not using this class at all.  I think it would be much better to give the GTK screencast logic its own little int/int record (not necessarily called anything like dimension).  Just define it package private or as an inner type of `TokenItem`.  This code really has no relation at all to the rest of FX (it is even GTK specific).  

Alternatively (which may be even better), avoid the creation of a dimension and just call `hasAllScreensOfSameSize(dimensions)` with the actual rectangles and have `TokenItem` figure it out using that information.

As for the `float` version of `Dimension2D`, I think we don't need this.  Just use the `double` one; everything in FX is doubles, and to be honest, the conversion we sometimes do to floats is a precision loss risk.

So, if it is up to me:
- Don't create any new dimension types; FX uses doubles, down casting to floats is not without risk.  Int variants are not needed in core FX code.
- Have TokenItem accept Rectangles in its `hasAllScreensOfSameSize` function.  I think you can change the logic to avoid creating a dimension class at all, or you can make a tiny `record ScreenSize(int w, int h)` defined as an inner class or even method class to do what it is currently doing.  
- Delete `com.sun.javafx.geom.Dimension` completely

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1653#issuecomment-2703192504

From jhendrikx at openjdk.org  Thu Mar  6 09:06:04 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 09:06:04 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v7]
In-Reply-To: <SbNFK7H0iMTptmSxQivz3gLzuw4vsFt8V__n2hNSHS8=.7369f8e1-58b5-4318-89cb-5259a6a7ac80@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <Ig7k1z_zJJt-KSrXaPA7H6fgt5qBtFuGR85q75rdAn8=.80dd0781-58c5-4be7-a846-7d62aaef308c@github.com>
 <SbNFK7H0iMTptmSxQivz3gLzuw4vsFt8V__n2hNSHS8=.7369f8e1-58b5-4318-89cb-5259a6a7ac80@github.com>
Message-ID: <6A8z1fO0QIyEvC9cb60lHnVnheEE9QUstSR2DOOznJc=.29a824f0-73ff-439d-8c46-3f177e7766c0@github.com>

On Thu, 6 Mar 2025 03:08:58 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I tested the new convergence check. If listener A and listener B fight over a value, it works, but if I add after then listener C that just prints what it sees without changing the value, it completes without an error.
> 
> Is it not possible to let the SOE be thrown naturally (by infinite recursion)?

Not without breaking one of the rules.  I can't get infinite recursion if I'm not calling the change listener that is causing it.   I'd have to call it either with `oldValue == newValue` (breaks Rule 2) or `badOldValue + sameNewValue` (breaks Rule 1 which is what `ExpressionHelper` does).

We can of course discuss this, but I think no `ChangeListener` is interested to be called with `oldValue == newValue` in edge cases.  It probably wouldn't require special logic on their parts though, so it could be considered.  The nasty case of adding/removing listeners to maintain a chain like node->scene->window would not break when both values are equal.

> > Note that the non-convergence detection logic is pretty smart, as the test case where multiple listeners are trying to agree upon a value that is divisible by 3, 5, 7 and 11 still works fine
> 
> And what about non-integer values, like custom objects or strings?

I fail to see how this would make a difference.  The test case demonstrates what happens if multiple listeners have non-conflicting rules defined, and it is not rejected just because multiple listeners are making changes, as long as they eventually reach an agreement.  Doing this with any other values should work just as well as long as there **exists** a solution (and the listeners at least make some effort to resolving it).  If there is no solution, or some listeners are just resetting values back, then there is no hope that it will ever converge.  So a listener that requires even values and another that requires uneven values -> no solution.  A listener that requires even values and one that requires positive values -> solution possible.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2703223673

From jhendrikx at openjdk.org  Thu Mar  6 09:48:05 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 09:48:05 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v8]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <Le0n5vgSUbRb8s4nBCl9x-UCTp8G8NjvrdnkrOZ62wQ=.a218dbb5-cab1-47fa-8d03-24499a0d7447@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix edge case with non-convergence detection

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/8e198cdb..dd714266

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=06-07

  Stats: 112 lines in 2 files changed: 79 ins; 16 del; 17 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From jhendrikx at openjdk.org  Thu Mar  6 09:48:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 09:48:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v7]
In-Reply-To: <SbNFK7H0iMTptmSxQivz3gLzuw4vsFt8V__n2hNSHS8=.7369f8e1-58b5-4318-89cb-5259a6a7ac80@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <Ig7k1z_zJJt-KSrXaPA7H6fgt5qBtFuGR85q75rdAn8=.80dd0781-58c5-4be7-a846-7d62aaef308c@github.com>
 <SbNFK7H0iMTptmSxQivz3gLzuw4vsFt8V__n2hNSHS8=.7369f8e1-58b5-4318-89cb-5259a6a7ac80@github.com>
Message-ID: <HoMlcUcZkF8YvP-psJ1aMUKbxzlm1V55hCv4AmBx9co=.da783d84-e30e-4898-b9f0-9b00377aec9c@github.com>

On Thu, 6 Mar 2025 03:08:58 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix docs
>
> I tested the new convergence check. If listener A and listener B fight over a value, it works, but if I add after then listener C that just prints what it sees without changing the value, it completes without an error.
> 
> Is it not possible to let the SOE be thrown naturally (by infinite recursion)?
> 
>> Note that the non-convergence detection logic is pretty smart, as the test case where multiple listeners are trying to agree upon a value that is divisible by 3, 5, 7 and 11 still works fine
> 
> And what about non-integer values, like custom objects or strings?

@nlisker I've fixed the edge case you found -- thanks very much for finding it; the extra listener would overwrite the progress value and so the aborted nested loop would go undetected. I added an additional test case to cover this.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2703325887

From mhanl at openjdk.org  Thu Mar  6 10:38:02 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 6 Mar 2025 10:38:02 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v6]
In-Reply-To: <mt_kO4AVu51QSTxBHVOQ2P6-V28gjRnaVRa52MjLf5g=.ace534cf-3778-40c3-83d6-a10dfff7e8d7@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <mt_kO4AVu51QSTxBHVOQ2P6-V28gjRnaVRa52MjLf5g=.ace534cf-3778-40c3-83d6-a10dfff7e8d7@github.com>
Message-ID: <wRok0ao9xmrfIsxo89-ErBTQ7WOaxnURLHNZszEZSOU=.1034cfc9-9696-4c2b-9fb8-fa9ead8ffed4@github.com>

On Wed, 5 Mar 2025 15:54:49 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - atomic boolean
>  - Merge branch 'master' into 8342565.stub.text.layout
>  - cleanup
>  - better test
>  - cleanup
>  - ... and 14 more: https://git.openjdk.org/jfx/compare/302a3dce...3650989a

Code looks good to me, some minor convention related things from my side.

modules/javafx.controls/src/test/addExports line 38:

> 36: --add-exports=javafx.graphics/com.sun.javafx.menu=ALL-UNNAMED
> 37: --add-exports=javafx.graphics/com.sun.javafx.text=ALL-UNNAMED
> 38: 

minor: extra added newline here

modules/javafx.graphics/src/main/java/com/sun/javafx/text/GlyphLayoutManager.java line 43:

> 41: public class GlyphLayoutManager {
> 42:     private static GlyphLayout reusableGL = newInstance();
> 43:     private static final AtomicBoolean guard = new AtomicBoolean(false);

if we follow the java standard, then this should be named `GUARD`

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayoutFactory.java line 34:

> 32: 
> 33: public class PrismTextLayoutFactory implements TextLayoutFactory {
> 34:     private static final PrismTextLayoutFactory factory = new PrismTextLayoutFactory();

Again, if we want to follow the practise this should be uppercase

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayoutFactory.java line 37:

> 35:     /* Same strategy as GlyphLayout */
> 36:     private static final TextLayout reusableTL = factory.createLayout();
> 37:     private static final AtomicBoolean guard = new AtomicBoolean(false);

same here

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2664025448
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983109268
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983105350
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983107627
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r1983107282

From kizune at openjdk.org  Thu Mar  6 13:36:07 2025
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 6 Mar 2025 13:36:07 GMT
Subject: Integrated: 8313556: Create implementation of NSAccessibilitySlider
 protocol
In-Reply-To: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
References: <hL0aAOebvGMSGHnIQhLd20bs5FgV7jfp5r6qfamZoUY=.fa54ef23-3718-41c7-9a62-3361f8d6b1f4@github.com>
Message-ID: <tyTW0P84wq_WvC8UBEC6fu_u6QhdZG8o1n0XTtf9pHU=.8e1cdef6-8ecb-4228-8ba2-a75b4e21c308@github.com>

On Tue, 29 Aug 2023 10:10:54 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Create implementation for Slider and Stepper accessibility protocols.
> Fix mapping.
> Fix performAction parameter type in declaration.

This pull request has now been integrated.

Changeset: c7091e1f
Author:    Alexander Zuev <kizune at openjdk.org>
Committer: Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c7091e1f57503e68c578ec890a4945a74d2d2978
Stats:     276 lines in 6 files changed: 273 ins; 0 del; 3 mod

8313556: Create implementation of NSAccessibilitySlider protocol
8313558: Create implementation of NSAccessibilityStepper protocol

Reviewed-by: arapte, angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1226

From jhendrikx at openjdk.org  Thu Mar  6 15:08:43 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 15:08:43 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v9]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <8zCB5oRxrJFm8hoJnd6K2fV3q4PaLgTIV84QcqlSfgs=.fb1afc61-0bb6-44e8-adfa-339f15a4ea87@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Simplified overly complicated non-convergence logic

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/dd714266..6608d3ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=07-08

  Stats: 91 lines in 2 files changed: 16 ins; 62 del; 13 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From jhendrikx at openjdk.org  Thu Mar  6 15:08:43 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 15:08:43 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v8]
In-Reply-To: <Le0n5vgSUbRb8s4nBCl9x-UCTp8G8NjvrdnkrOZ62wQ=.a218dbb5-cab1-47fa-8d03-24499a0d7447@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <Le0n5vgSUbRb8s4nBCl9x-UCTp8G8NjvrdnkrOZ62wQ=.a218dbb5-cab1-47fa-8d03-24499a0d7447@github.com>
Message-ID: <HUNuaELLtsomYAY4m5uAehyM0Kxv3UfKc9M6m0eGSbQ=.4fb4e6e9-2820-443c-9d12-5943c603660d@github.com>

On Thu, 6 Mar 2025 09:48:05 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
>> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
>> 
>> # About nested changes
>> 
>> Nested changes are simply changes...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix edge case with non-convergence detection

I made the non-convergence logic way too complicated.  Basically where in the old code (before I did this logic) there was a `break` there is now a throw exception... an incorrectly written test caused me to write it way more complicated than it needed to be.  The simple rule now for non-convergence is that if any loop is aborted because the value changed back to its original, that automatically means it is non-convergent.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2704113040

From jhendrikx at openjdk.org  Thu Mar  6 15:12:17 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 15:12:17 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v10]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <c2hUWTC9jttR7QEPw36bqM5AHSlimFxuWPpITfyLM8g=.00ef293a-8d5c-4c73-9f78-62f076aee061@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix docs

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/6608d3ba..5470edb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From angorya at openjdk.org  Thu Mar  6 15:40:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 15:40:09 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
Message-ID: <A62sWbQimA-wYY94xbzjYeUl__AF6oqFa8adA3-d-dA=.071e470d-56f4-4a10-874c-ba1591b911e6@github.com>

On Wed, 5 Mar 2025 21:18:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - Merge branch 'master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge branch 'master' into ag.text.layout.api
>  - segments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd

please review

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1596#issuecomment-2704205653

From angorya at openjdk.org  Thu Mar  6 15:51:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 15:51:16 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v7]
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <BS0tbq9EXeNXC--m6P4SrfuuWT3jzh2LXGAvsmhgjMg=.e305dcfc-56fc-4c9c-94d4-8b153d47be02@github.com>

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - atomic boolean
 - Merge branch 'master' into 8342565.stub.text.layout
 - cleanup
 - ... and 16 more: https://git.openjdk.org/jfx/compare/95ec7f55...1c4e5a80

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1667/files
  - new: https://git.openjdk.org/jfx/pull/1667/files/3650989a..1c4e5a80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=05-06

  Stats: 715 lines in 22 files changed: 553 ins; 102 del; 60 mod
  Patch: https://git.openjdk.org/jfx/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667

PR: https://git.openjdk.org/jfx/pull/1667

From angorya at openjdk.org  Thu Mar  6 16:05:53 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 16:05:53 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v8]
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <sjY0ealMePvaZsgFMDYzeP9p66b1xwMYKuNPZVdz2pk=.d845eef4-e4d5-4254-b58d-7de81b57be2e@github.com>

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  fixed bad merge

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1667/files
  - new: https://git.openjdk.org/jfx/pull/1667/files/1c4e5a80..0e9e8ee6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=06-07

  Stats: 41 lines in 2 files changed: 0 ins; 13 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667

PR: https://git.openjdk.org/jfx/pull/1667

From jhendrikx at openjdk.org  Thu Mar  6 16:21:33 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 6 Mar 2025 16:21:33 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
> 
> # About nested changes
> 
> Nested changes are simply changes that are made to a property that is currently in the process of notifying its listeners. This...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Fix non-convergence logic one more time...

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/5470edb3..5863932f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=10
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=09-10

  Stats: 149 lines in 2 files changed: 114 ins; 23 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From angorya at openjdk.org  Thu Mar  6 16:21:52 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 16:21:52 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  Revert "fixed bad merge"
  
  This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1667/files
  - new: https://git.openjdk.org/jfx/pull/1667/files/0e9e8ee6..e18e49a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=07-08

  Stats: 41 lines in 2 files changed: 13 ins; 0 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667

PR: https://git.openjdk.org/jfx/pull/1667

From kcr at openjdk.org  Thu Mar  6 22:02:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Mar 2025 22:02:06 GMT
Subject: RFR: 8277000: Tree-/TableRowSkin: replace listener to
 fixedCellSize by live lookup [v5]
In-Reply-To: <qfbP0wEAsYQEhq-VVRCX6IcI6ZV-VLd3pSFf9bxy8Oo=.512d7a92-b8da-4a8b-a746-b62010291dd7@github.com>
References: <C9DCt4HLNulh3bxF1ZnIbd1WxtJcxnslOcdkY_srAhg=.3c3ae808-45a2-4e0c-a55c-44fa1fdf1305@github.com>
 <qfbP0wEAsYQEhq-VVRCX6IcI6ZV-VLd3pSFf9bxy8Oo=.512d7a92-b8da-4a8b-a746-b62010291dd7@github.com>
Message-ID: <ffMBGbmAuHNgvkGuMqVj5oKiKa_DsMJtcjzou6CLRMU=.6179ebb2-16c4-4206-8923-581ec8ace69f@github.com>

On Mon, 17 Feb 2025 22:56:56 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR improves the `Tree-/TableRowSkin` code by doing a normal live lookup for the `fixedCellSize` instead of adding listener just to update variables(`fixedCellSizeEnabled` and `fixedCellSize`) which can otherwise be also just lookup'd without the hassle of listeners.
>> 
>> While this is mostly a cleanup, it does improve the state of the `Tree-/TableRow`, as when the `TableRowSkinBase` constructor is called, the variables are not yet set.
>> 
>> It is also consistent with the other cells, see also [JDK-8246745](https://bugs.openjdk.org/browse/JDK-8246745).
>> Helps a bit with [JDK-8185887](https://bugs.openjdk.org/browse/JDK-8185887) (https://github.com/openjdk/jfx/pull/1644), but as written above, not required as there is no (visible) effect.
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add as javadoc

@arapte Can you be the second reviewer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1645#issuecomment-2705036479

From mhanl at openjdk.org  Thu Mar  6 23:35:11 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Thu, 6 Mar 2025 23:35:11 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
Message-ID: <CjFYXzSSJx0ZqXtIweAaEDxGUTezhu-dwnzpw8AuOKA=.cf5c0adb-525a-4d6e-8043-fb65f2e2b0e6@github.com>

On Thu, 6 Mar 2025 16:21:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "fixed bad merge"
>   
>   This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.

Nice Improvement for the tests and utilizing the existing abstraction of the layout code.

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2665852619

From angorya at openjdk.org  Thu Mar  6 23:35:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 23:35:40 GMT
Subject: RFR: 8351368: RichTextArea: exception pasting from Word
Message-ID: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>

The original code used String attribute keys.

I'd like to backport this fix to jfx24u.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jfx/pull/1731/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1731&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351368
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1731.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1731/head:pull/1731

PR: https://git.openjdk.org/jfx/pull/1731

From angorya at openjdk.org  Thu Mar  6 23:40:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 6 Mar 2025 23:40:05 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v2]
In-Reply-To: <6Oo6L7G6zNL6cNZX-MOMVJI1Dz_er60aj5euXudRBLw=.b57e4f58-c3c7-4ad4-ade2-0ca402fa4b34@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <mbI9wwPE3ydhdq4coXPFEt7s4K0NQnB2AU2sjADm0wA=.b33233b5-3d43-41fe-99ce-f8d88a0d2aad@github.com>
 <6Oo6L7G6zNL6cNZX-MOMVJI1Dz_er60aj5euXudRBLw=.b57e4f58-c3c7-4ad4-ade2-0ca402fa4b34@github.com>
Message-ID: <1QsRn9mqFGMHQeQ4tj9pFcIYMlY1NKKsMsGQiS2Eybc=.ec919895-414f-4872-bd83-785dd1aae1aa@github.com>

On Tue, 4 Feb 2025 08:53:31 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - atomic boolean
>>  - Merge branch 'master' into 8342565.stub.text.layout
>>  - cleanup
>>  - better test
>>  - cleanup
>>  - more magic
>>  - magic numbers
>>  - more
>>  - add exports
>>  - stub fonts
>>  - ... and 9 more: https://git.openjdk.org/jfx/compare/6ed82938...5010278f
>
> I think this is a good change, completely utilizing that the text layout code is abstracted away for good.
> Changes look good to me so far. 
> Some tests are hard to understand the changes, but that is a preexisting problem (especially if the name of the test is just `rt_xxxx`).
> Not sure about the code style of using `S`, `M` or `L` as variable names (minor), so I will see what other reviewers say about this.

thank you @Maran23

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2705176354

From kcr at openjdk.org  Thu Mar  6 23:54:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 6 Mar 2025 23:54:00 GMT
Subject: RFR: 8351368: RichTextArea: exception pasting from Word
In-Reply-To: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
References: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
Message-ID: <tlypYf71k8_rnUh1Rr_xyOaJobgobcJ-n04j5naPi-o=.f9179dc6-ca03-4a9c-8383-1bf54534fc82@github.com>

On Thu, 6 Mar 2025 23:16:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The original code used String attribute keys.
> 
> I'd like to backport this fix to jfx24u.

This is a simple enough fix that a single reviewer should be sufficient.

modules/jfx.incubator.richtext/src/main/java/com/sun/jfx/incubator/scene/control/richtext/rtf/RTFReader.java line 787:

> 785:                 Object stype = defined.getAttribute(STYLE_TYPE);
> 786:                 Map<Integer, Style> toMap;
> 787:                 if (STYLE_SECTION.equals(stype)) {

Since this is a marker object, should it be `==` rather than `.equals`? They are equivalent, so it's up to you.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1731#pullrequestreview-2665858008
PR Review Comment: https://git.openjdk.org/jfx/pull/1731#discussion_r1984190205

From jhendrikx at openjdk.org  Fri Mar  7 06:28:34 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Mar 2025 06:28:34 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
Message-ID: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>

8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

-------------

Commit messages:
 - Add test case
 - Prevent redundant compute value calls

Changes: https://git.openjdk.org/jfx/pull/1730/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1730&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351276
  Stats: 145 lines in 3 files changed: 138 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1730.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1730/head:pull/1730

PR: https://git.openjdk.org/jfx/pull/1730

From mstrauss at openjdk.org  Fri Mar  7 13:58:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 13:58:10 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
Message-ID: <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>

On Wed, 5 Mar 2025 18:20:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - enforced fx application thread
>> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
>> - clarified `ComboBoxBase::show`
>> - added a headful test `TestThreadingRestrictions`
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350048.enforce
>  - review comments
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8350048.enforce
>  - fixed node init test
>  - all tests
>  - initial test

Marked as reviewed by mstrauss (Reviewer).

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1187:

> 1185:      * This call is equivalent to {@code hide()}.
> 1186:      * @throws IllegalStateException if this method is called on a thread
> 1187:      * other than the JavaFX Application Thread.

Minor: add a blank line before `@throws`. I also think it's easier to read docs when multi-line text for a javadoc tag is indented, either by four spaces or lined up with the beginning of the first line of text (i.e. with the beginning of `IllegalStateException`).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1717#pullrequestreview-2667326637
PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985100841

From crschnick at xpipe.io  Fri Mar  7 14:24:54 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 7 Mar 2025 15:24:54 +0100
Subject: JVM crashes on macOS when entering too many nested event loops
Message-ID: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>

Hello,

I have attached a JVM fatal error log that seemingly was caused by our 
JavaFX application entering too many nested event loops, which macOS 
apparently doesn't like.

As far as I know, there is no upper limit defined on how often an event 
loop can be nested, so I think this is a bug that can occur in rare 
situations.

Best
Christopher Schnick
-------------- next part --------------
-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               xpiped [4582]
Path:                  /Applications/XPipe.app/Contents/MacOS/xpiped
Identifier:            io.xpipe.app
Version:               15.3 (15.3)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2025-03-07 05:03:02.0359 -0500
OS Version:            macOS 15.3.1 (24D70)
Report Version:        12
Anonymous UUID:        7DF0C6D2-9B21-B647-8359-B8BFCA84AD12

Sleep/Wake UUID:       29F56F1C-40A0-4598-A9E6-CF9D1506B168

Time Awake Since Boot: 33000 seconds
Time Since Wake:       299 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x000000018b494b98

Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [4582]

Application Specific Information:
Too many nested CFRunLoopRuns


Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   CoreFoundation                	       0x18b494b98 CFRunLoopRunSpecific.cold.1 + 16
1   CoreFoundation                	       0x18b326828 CFRunLoopRunSpecific + 832
2   Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
3   libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
4   libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
5   ???                           	       0x1111cc954 ???
6   ???                           	       0x10ac48f70 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c95a0 ???
12  ???                           	       0x1111c95a0 ???
13  ???                           	       0x1111c9120 ???
14  ???                           	       0x1111c9120 ???
15  ???                           	       0x1111c9120 ???
16  ???                           	       0x1111c95a0 ???
17  ???                           	       0x1111c95a0 ???
18  ???                           	       0x1111c4154 ???
19  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
20  libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
21  libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
22  libglass.dylib                	       0x13d899214 0x13d890000 + 37396
23  Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
24  CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
25  CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
26  CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
27  CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
28  CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
29  Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
30  libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
31  libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
32  ???                           	       0x1111cc954 ???
33  ???                           	       0x10ac48f70 ???
34  ???                           	       0x1111c9120 ???
35  ???                           	       0x1111c9120 ???
36  ???                           	       0x1111c9120 ???
37  ???                           	       0x1111c9120 ???
38  ???                           	       0x1111c95a0 ???
39  ???                           	       0x1111c95a0 ???
40  ???                           	       0x1111c9120 ???
41  ???                           	       0x1111c9120 ???
42  ???                           	       0x1111c9120 ???
43  ???                           	       0x1111c95a0 ???
44  ???                           	       0x1111c95a0 ???
45  ???                           	       0x1111c4154 ???
46  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
47  libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
48  libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
49  libglass.dylib                	       0x13d899214 0x13d890000 + 37396
50  Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
51  CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
52  CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
53  CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
54  CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
55  CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
56  Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
57  libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
58  libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
59  ???                           	       0x1111cc954 ???
60  ???                           	       0x10ac48f70 ???
61  ???                           	       0x1111c9120 ???
62  ???                           	       0x1111c9120 ???
63  ???                           	       0x1111c9120 ???
64  ???                           	       0x1111c9120 ???
65  ???                           	       0x1111c95a0 ???
66  ???                           	       0x1111c95a0 ???
67  ???                           	       0x1111c9120 ???
68  ???                           	       0x1111c9120 ???
69  ???                           	       0x1111c9120 ???
70  ???                           	       0x1111c95a0 ???
71  ???                           	       0x1111c95a0 ???
72  ???                           	       0x1111c4154 ???
73  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
74  libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
75  libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
76  libglass.dylib                	       0x13d899214 0x13d890000 + 37396
77  Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
78  CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
79  CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
80  CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
81  CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
82  CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
83  Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
84  libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
85  libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
86  ???                           	       0x1111cc954 ???
87  ???                           	       0x10ac48f70 ???
88  ???                           	       0x1111c9120 ???
89  ???                           	       0x1111c9120 ???
90  ???                           	       0x1111c9120 ???
91  ???                           	       0x1111c9120 ???
92  ???                           	       0x1111c95a0 ???
93  ???                           	       0x1111c95a0 ???
94  ???                           	       0x1111c9120 ???
95  ???                           	       0x1111c9120 ???
96  ???                           	       0x1111c9120 ???
97  ???                           	       0x1111c95a0 ???
98  ???                           	       0x1111c95a0 ???
99  ???                           	       0x1111c4154 ???
100 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
101 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
102 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
103 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
104 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
105 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
106 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
107 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
108 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
109 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
110 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
111 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
112 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
113 ???                           	       0x1111cc954 ???
114 ???                           	       0x10ac48f70 ???
115 ???                           	       0x1111c9120 ???
116 ???                           	       0x1111c9120 ???
117 ???                           	       0x1111c9120 ???
118 ???                           	       0x1111c9120 ???
119 ???                           	       0x1111c95a0 ???
120 ???                           	       0x1111c95a0 ???
121 ???                           	       0x1111c9120 ???
122 ???                           	       0x1111c9120 ???
123 ???                           	       0x1111c9120 ???
124 ???                           	       0x1111c95a0 ???
125 ???                           	       0x1111c95a0 ???
126 ???                           	       0x1111c4154 ???
127 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
128 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
129 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
130 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
131 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
132 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
133 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
134 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
135 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
136 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
137 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
138 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
139 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
140 ???                           	       0x1111cc954 ???
141 ???                           	       0x10ac48f70 ???
142 ???                           	       0x1111c9120 ???
143 ???                           	       0x1111c9120 ???
144 ???                           	       0x1111c9120 ???
145 ???                           	       0x1111c9120 ???
146 ???                           	       0x1111c95a0 ???
147 ???                           	       0x1111c95a0 ???
148 ???                           	       0x1111c9120 ???
149 ???                           	       0x1111c9120 ???
150 ???                           	       0x1111c9120 ???
151 ???                           	       0x1111c95a0 ???
152 ???                           	       0x1111c95a0 ???
153 ???                           	       0x1111c4154 ???
154 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
155 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
156 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
157 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
158 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
159 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
160 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
161 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
162 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
163 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
164 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
165 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
166 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
167 ???                           	       0x1111cc954 ???
168 ???                           	       0x10ac48f70 ???
169 ???                           	       0x1111c9120 ???
170 ???                           	       0x1111c9120 ???
171 ???                           	       0x1111c9120 ???
172 ???                           	       0x1111c9120 ???
173 ???                           	       0x1111c95a0 ???
174 ???                           	       0x1111c95a0 ???
175 ???                           	       0x1111c9120 ???
176 ???                           	       0x1111c9120 ???
177 ???                           	       0x1111c9120 ???
178 ???                           	       0x1111c95a0 ???
179 ???                           	       0x1111c95a0 ???
180 ???                           	       0x1111c4154 ???
181 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
182 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
183 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
184 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
185 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
186 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
187 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
188 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
189 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
190 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
191 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
192 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
193 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
194 ???                           	       0x1111cc954 ???
195 ???                           	       0x10ac48f70 ???
196 ???                           	       0x1111c9120 ???
197 ???                           	       0x1111c9120 ???
198 ???                           	       0x1111c9120 ???
199 ???                           	       0x1111c9120 ???
200 ???                           	       0x1111c95a0 ???
201 ???                           	       0x1111c95a0 ???
202 ???                           	       0x1111c9120 ???
203 ???                           	       0x1111c9120 ???
204 ???                           	       0x1111c9120 ???
205 ???                           	       0x1111c95a0 ???
206 ???                           	       0x1111c95a0 ???
207 ???                           	       0x1111c4154 ???
208 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
209 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
210 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
211 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
212 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
213 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
214 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
215 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
216 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
217 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
218 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
219 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
220 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
221 ???                           	       0x1111cc954 ???
222 ???                           	       0x10ac48f70 ???
223 ???                           	       0x1111c9120 ???
224 ???                           	       0x1111c9120 ???
225 ???                           	       0x1111c9120 ???
226 ???                           	       0x1111c9120 ???
227 ???                           	       0x1111c95a0 ???
228 ???                           	       0x1111c95a0 ???
229 ???                           	       0x1111c9120 ???
230 ???                           	       0x1111c9120 ???
231 ???                           	       0x1111c9120 ???
232 ???                           	       0x1111c95a0 ???
233 ???                           	       0x1111c95a0 ???
234 ???                           	       0x1111c4154 ???
235 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
236 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
237 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
238 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
239 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
240 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
241 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
242 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
243 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
244 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
245 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
246 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
247 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
248 ???                           	       0x1111cc954 ???
249 ???                           	       0x10ac48f70 ???
250 ???                           	       0x1111c9120 ???
251 ???                           	       0x1111c9120 ???
252 ???                           	       0x1111c9120 ???
253 ???                           	       0x1111c9120 ???
254 ???                           	       0x1111c95a0 ???
255 ???                           	       0x1111c95a0 ???
256 ???                           	       0x1111c9120 ???
257 ???                           	       0x1111c9120 ???
258 ???                           	       0x1111c9120 ???
259 ???                           	       0x1111c95a0 ???
260 ???                           	       0x1111c95a0 ???
261 ???                           	       0x1111c4154 ???
262 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
263 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
264 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
265 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
266 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
267 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
268 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
269 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
270 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
271 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
272 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
273 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
274 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
275 ???                           	       0x1111cc954 ???
276 ???                           	       0x10ac48f70 ???
277 ???                           	       0x1111c9120 ???
278 ???                           	       0x1111c9120 ???
279 ???                           	       0x1111c9120 ???
280 ???                           	       0x1111c9120 ???
281 ???                           	       0x1111c95a0 ???
282 ???                           	       0x1111c95a0 ???
283 ???                           	       0x1111c9120 ???
284 ???                           	       0x1111c9120 ???
285 ???                           	       0x1111c9120 ???
286 ???                           	       0x1111c95a0 ???
287 ???                           	       0x1111c95a0 ???
288 ???                           	       0x1111c4154 ???
289 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
290 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
291 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
292 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
293 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
294 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
295 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
296 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
297 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
298 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
299 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
300 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
301 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
302 ???                           	       0x1111cc954 ???
303 ???                           	       0x10ac48f70 ???
304 ???                           	       0x1111c9120 ???
305 ???                           	       0x1111c9120 ???
306 ???                           	       0x1111c9120 ???
307 ???                           	       0x1111c9120 ???
308 ???                           	       0x1111c95a0 ???
309 ???                           	       0x1111c95a0 ???
310 ???                           	       0x1111c9120 ???
311 ???                           	       0x1111c9120 ???
312 ???                           	       0x1111c9120 ???
313 ???                           	       0x1111c95a0 ???
314 ???                           	       0x1111c95a0 ???
315 ???                           	       0x1111c4154 ???
316 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
317 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
318 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
319 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
320 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
321 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
322 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
323 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
324 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
325 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
326 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
327 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
328 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
329 ???                           	       0x1111cc954 ???
330 ???                           	       0x10ac48f70 ???
331 ???                           	       0x1111c9120 ???
332 ???                           	       0x1111c9120 ???
333 ???                           	       0x1111c9120 ???
334 ???                           	       0x1111c9120 ???
335 ???                           	       0x1111c95a0 ???
336 ???                           	       0x1111c95a0 ???
337 ???                           	       0x1111c9120 ???
338 ???                           	       0x1111c9120 ???
339 ???                           	       0x1111c9120 ???
340 ???                           	       0x1111c95a0 ???
341 ???                           	       0x1111c95a0 ???
342 ???                           	       0x1111c4154 ???
343 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
344 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
345 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
346 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
347 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
348 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
349 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
350 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
351 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
352 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
353 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
354 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
355 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
356 ???                           	       0x1111cc954 ???
357 ???                           	       0x10ac48f70 ???
358 ???                           	       0x1111c9120 ???
359 ???                           	       0x1111c9120 ???
360 ???                           	       0x1111c9120 ???
361 ???                           	       0x1111c9120 ???
362 ???                           	       0x1111c95a0 ???
363 ???                           	       0x1111c95a0 ???
364 ???                           	       0x1111c9120 ???
365 ???                           	       0x1111c9120 ???
366 ???                           	       0x1111c9120 ???
367 ???                           	       0x1111c95a0 ???
368 ???                           	       0x1111c95a0 ???
369 ???                           	       0x1111c4154 ???
370 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
371 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
372 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
373 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
374 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
375 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
376 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
377 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
378 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
379 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
380 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
381 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
382 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
383 ???                           	       0x1111cc954 ???
384 ???                           	       0x10ac48f70 ???
385 ???                           	       0x1111c9120 ???
386 ???                           	       0x1111c9120 ???
387 ???                           	       0x1111c9120 ???
388 ???                           	       0x1111c9120 ???
389 ???                           	       0x1111c95a0 ???
390 ???                           	       0x1111c95a0 ???
391 ???                           	       0x1111c9120 ???
392 ???                           	       0x1111c9120 ???
393 ???                           	       0x1111c9120 ???
394 ???                           	       0x1111c95a0 ???
395 ???                           	       0x1111c95a0 ???
396 ???                           	       0x1111c4154 ???
397 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
398 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
399 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
400 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
401 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
402 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
403 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
404 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
405 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
406 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
407 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
408 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
409 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
410 ???                           	       0x1111cc954 ???
411 ???                           	       0x10ac48f70 ???
412 ???                           	       0x1111c9120 ???
413 ???                           	       0x1111c9120 ???
414 ???                           	       0x1111c9120 ???
415 ???                           	       0x1111c9120 ???
416 ???                           	       0x1111c95a0 ???
417 ???                           	       0x1111c95a0 ???
418 ???                           	       0x1111c9120 ???
419 ???                           	       0x1111c9120 ???
420 ???                           	       0x1111c9120 ???
421 ???                           	       0x1111c95a0 ???
422 ???                           	       0x1111c95a0 ???
423 ???                           	       0x1111c4154 ???
424 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
425 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
426 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
427 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
428 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
429 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
430 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
431 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
432 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
433 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
434 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
435 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
436 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
437 ???                           	       0x1111cc954 ???
438 ???                           	       0x10ac48f70 ???
439 ???                           	       0x1111c9120 ???
440 ???                           	       0x1111c9120 ???
441 ???                           	       0x1111c9120 ???
442 ???                           	       0x1111c9120 ???
443 ???                           	       0x1111c95a0 ???
444 ???                           	       0x1111c95a0 ???
445 ???                           	       0x1111c9120 ???
446 ???                           	       0x1111c9120 ???
447 ???                           	       0x1111c9120 ???
448 ???                           	       0x1111c95a0 ???
449 ???                           	       0x1111c95a0 ???
450 ???                           	       0x1111c4154 ???
451 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
452 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
453 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
454 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
455 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
456 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
457 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
458 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
459 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
460 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
461 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
462 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
463 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
464 ???                           	       0x1111cc954 ???
465 ???                           	       0x10ac48f70 ???
466 ???                           	       0x1111c9120 ???
467 ???                           	       0x1111c9120 ???
468 ???                           	       0x1111c9120 ???
469 ???                           	       0x1111c9120 ???
470 ???                           	       0x1111c95a0 ???
471 ???                           	       0x1111c95a0 ???
472 ???                           	       0x1111c9120 ???
473 ???                           	       0x1111c9120 ???
474 ???                           	       0x1111c9120 ???
475 ???                           	       0x1111c95a0 ???
476 ???                           	       0x1111c95a0 ???
477 ???                           	       0x1111c4154 ???
478 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
479 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
480 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
481 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
482 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
483 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28
484 CoreFoundation                	       0x18b328838 __CFRunLoopDoSource0 + 176
485 CoreFoundation                	       0x18b32859c __CFRunLoopDoSources0 + 244
486 CoreFoundation                	       0x18b327138 __CFRunLoopRun + 840
487 CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
488 Foundation                    	       0x18c4f7518 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 212
489 libglass.dylib                	       0x13d89b404 0x13d890000 + 46084
490 libglass.dylib                	       0x13d89bf38 Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl + 56
491 ???                           	       0x1111cc954 ???
492 ???                           	       0x10ac48f70 ???
493 ???                           	       0x1111c9120 ???
494 ???                           	       0x1111c9120 ???
495 ???                           	       0x1111c9120 ???
496 ???                           	       0x1111c9120 ???
497 ???                           	       0x1111c95a0 ???
498 ???                           	       0x1111c95a0 ???
499 ???                           	       0x1111c9120 ???
500 ???                           	       0x1111c9120 ???
501 ???                           	       0x1111c9120 ???
502 ???                           	       0x1111c95a0 ???
503 ???                           	       0x1111c95a0 ???
504 ???                           	       0x1111c4154 ???
505 libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
506 libjvm.dylib                  	       0x104548350 jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*) + 368
507 libjvm.dylib                  	       0x10454bd4c jni_CallStaticVoidMethod + 276
508 libglass.dylib                	       0x13d899214 0x13d890000 + 37396
509 Foundation                    	       0x18c5157a0 __NSThreadPerformPerform + 264
510 CoreFoundation                	       0x18b3288a4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28

Thread 1:
0   libsystem_kernel.dylib        	       0x18b200cac __ulock_wait + 8
1   libsystem_pthread.dylib       	       0x18b2427d4 _pthread_join + 612
2   libjli.dylib                  	       0x102de1588 CallJavaMainInNewThread + 184
3   libjli.dylib                  	       0x102de0218 ContinueInNewThread + 148
4   libjli.dylib                  	       0x102dddc34 JLI_Launch + 5632
5   xpiped                        	       0x102d28084 jvmLauncherStartJvm + 328
6   xpiped                        	       0x102d26a84 Jvm::launch() + 716
7   xpiped                        	       0x102d2bdb0 app::launch(std::nothrow_t const&, void (*)(), LogAppender*) + 236
8   libjli.dylib                  	       0x102de1e64 apple_main + 88
9   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 2:
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104855430 PlatformMonitor::wait(unsigned long long) + 144
3   libjvm.dylib                  	       0x104814750 Monitor::wait(unsigned long long) + 124
4   libjvm.dylib                  	       0x1049b4418 Threads::destroy_vm() + 108
5   libjvm.dylib                  	       0x10455ca6c jni_DestroyJavaVM + 220
6   libjli.dylib                  	       0x102dde92c JavaMain + 1324
7   libjli.dylib                  	       0x102de15d0 ThreadJavaMain + 12
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 3:: Java: GC Thread#0
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 4:: Java: G1 Main Marker
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104855430 PlatformMonitor::wait(unsigned long long) + 144
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x1043d6644 G1ConcurrentMarkThread::run_service() + 176
5   libjvm.dylib                  	       0x1042d62f8 ConcurrentGCThread::run() + 36
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 5:: Java: G1 Conc#0
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 6:: Java: G1 Refine#0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x1043df384 G1PrimaryConcurrentRefineThread::wait_for_completed_buffers() + 68
5   libjvm.dylib                  	       0x1043deee8 G1ConcurrentRefineThread::run_service() + 144
6   libjvm.dylib                  	       0x1042d62f8 ConcurrentGCThread::run() + 36
7   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
8   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
9   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 7:: Java: G1 Service
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x10442b840 G1ServiceThread::wait_for_task() + 120
5   libjvm.dylib                  	       0x10442bb2c G1ServiceThread::run_service() + 44
6   libjvm.dylib                  	       0x1042d62f8 ConcurrentGCThread::run() + 36
7   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
8   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
9   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 8:: Java: VM Periodic Task Thread
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x104829e78 WatcherThread::sleep() const + 152
5   libjvm.dylib                  	       0x104829f54 WatcherThread::run() + 60
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 9:: Java: VM Thread
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x104a335e4 VMThread::wait_for_operation() + 444
5   libjvm.dylib                  	       0x104a32764 VMThread::run() + 188
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 10:: Java: Reference Handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104855430 PlatformMonitor::wait(unsigned long long) + 144
3   libjvm.dylib                  	       0x104814750 Monitor::wait(unsigned long long) + 124
4   libjvm.dylib                  	       0x1045a5a94 JVM_WaitForReferencePendingList + 200
5   ???                           	       0x1111cc954 ???
6   ???                           	       0x10b991ba4 ???
7   ???                           	       0x1111c4154 ???
8   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
9   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
10  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
11  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
12  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
13  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
14  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
15  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
16  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 11:: Java: Finalizer
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854700 PlatformEvent::park() + 120
3   libjvm.dylib                  	       0x1048322f4 ObjectMonitor::wait(long, bool, JavaThread*) + 1340
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x1111cc954 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c8f40 ???
12  ???                           	       0x1111c8f40 ???
13  ???                           	       0x1111c4154 ???
14  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
15  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
16  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
17  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
18  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
19  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
20  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
21  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
22  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 12:: Java: Signal Dispatcher
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x1048fa4b0 os::signal_wait() + 180
3   libjvm.dylib                  	       0x104847928 signal_thread_entry(JavaThread*, JavaThread*) + 76
4   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
5   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
6   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
7   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
8   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 13:: Java: Service Thread
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104855430 PlatformMonitor::wait(unsigned long long) + 144
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x1048e5b3c ServiceThread::service_thread_entry(JavaThread*, JavaThread*) + 508
5   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 14:: Java: Monitor Deflation Thread
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x1048095f4 MonitorDeflationThread::monitor_deflation_thread_entry(JavaThread*, JavaThread*) + 252
5   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 15:: Java: JVMCI-native CompilerThread0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x104814750 Monitor::wait(unsigned long long) + 124
4   libjvm.dylib                  	       0x1045c1260 JVMCICompiler::on_empty_queue(CompileQueue*, CompilerThread*) + 128
5   libjvm.dylib                  	       0x1042bc154 CompileQueue::get(CompilerThread*) + 536
6   libjvm.dylib                  	       0x1042bf930 CompileBroker::compiler_thread_loop() + 752
7   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
8   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
9   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
10  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
11  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 16:: Java: C1 CompilerThread0
0   libjvm.dylib                  	       0x1041479ac AbstractAssembler::bind(Label&) + 36
1   libjvm.dylib                  	       0x1041a59d4 LIR_Assembler::emit_opLabel(LIR_OpLabel*) + 28
2   libjvm.dylib                  	       0x1041a5054 LIR_Assembler::emit_lir_list(LIR_List*) + 156
3   libjvm.dylib                  	       0x1041a50fc LIR_Assembler::emit_code(BlockList*) + 116
4   libjvm.dylib                  	       0x104178cf0 Compilation::emit_code_body() + 220
5   libjvm.dylib                  	       0x1041796b0 Compilation::compile_java_method() + 648
6   libjvm.dylib                  	       0x10417993c Compilation::compile_method() + 368
7   libjvm.dylib                  	       0x104179c44 Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*) + 372
8   libjvm.dylib                  	       0x10417b4ac Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*) + 92
9   libjvm.dylib                  	       0x1042c00bc CompileBroker::invoke_compiler_on_method(CompileTask*) + 1216
10  libjvm.dylib                  	       0x1042bfa08 CompileBroker::compiler_thread_loop() + 968
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 17:: Java: Common-Cleaner
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111a4b4c8 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 18:: Java: Notification Thread
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104855430 PlatformMonitor::wait(unsigned long long) + 144
3   libjvm.dylib                  	       0x1048146bc Monitor::wait_without_safepoint_check(unsigned long long) + 48
4   libjvm.dylib                  	       0x10482a52c NotificationThread::notification_thread_entry(JavaThread*, JavaThread*) + 164
5   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
6   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
7   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 19:: Java: referenceGC
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1044e4d1c JavaThread::sleep_nanos(long) + 224
4   libjvm.dylib                  	       0x1045a39c8 JVM_SleepNanos + 264
5   ???                           	       0x111aa8fe4 ???
6   ???                           	       0x111a3ccb4 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c95a0 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c4154 ???
11  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
12  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
13  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
14  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
15  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
16  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
17  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
18  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
19  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 20:: Java: GC Thread#1
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 21:: Java: GC Thread#2
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 22:: Java: GC Thread#3
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 23:: Java: GC Thread#4
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 24:: Java: GC Thread#5
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 25:: Java: GC Thread#6
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 26:: Java: GC Thread#7
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 27:: Java: GC Thread#8
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 28:: Java: GC Thread#9
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 29:: com.apple.NSEventThread
0   libsystem_kernel.dylib        	       0x18b1fef54 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x18b211604 mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x18b207af8 mach_msg_overwrite + 480
3   libsystem_kernel.dylib        	       0x18b1ff29c mach_msg + 24
4   CoreFoundation                	       0x18b328a4c __CFRunLoopServiceMachPort + 160
5   CoreFoundation                	       0x18b3272ac __CFRunLoopRun + 1212
6   CoreFoundation                	       0x18b326734 CFRunLoopRunSpecific + 588
7   AppKit                        	       0x18efc3278 _NSEventThread + 148
8   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
9   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 30:: Java: Java2D Queue Flusher
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1048322d4 ObjectMonitor::wait(long, bool, JavaThread*) + 1308
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x11197dcdc ???
7   ???                           	       0x111a2f3bc ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 31:: Java: Java2D Disposer
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x1111cc954 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c9420 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c95a0 ???
11  ???                           	       0x1111c9120 ???
12  ???                           	       0x1111c8f40 ???
13  ???                           	       0x1111c8f40 ???
14  ???                           	       0x1111c95a0 ???
15  ???                           	       0x1111c9120 ???
16  ???                           	       0x1111c4154 ???
17  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
18  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
19  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
20  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
21  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
22  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
23  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
24  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
25  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 32:: Java: QuantumRenderer-0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c95a0 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c4154 ???
11  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
12  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
13  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
14  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
15  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
16  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
17  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
18  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
19  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 33:: Java: InvokeLaterDispatcher
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 34:: Java: Prism Font Disposer
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c8f40 ???
8   ???                           	       0x1111c8f40 ???
9   ???                           	       0x1111c95a0 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c4154 ???
12  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
13  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
14  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
15  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
16  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
17  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
18  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
19  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
20  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 35:: Java: app-wait
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c8fa0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c9120 ???
12  ???                           	       0x1111c9120 ???
13  ???                           	       0x1111c9120 ???
14  ???                           	       0x1111c95a0 ???
15  ???                           	       0x1111c9120 ???
16  ???                           	       0x1111c4154 ???
17  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
18  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
19  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
20  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
21  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
22  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
23  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
24  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
25  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 36:: Java: VirtualThread-unparker
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c4154 ???
11  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
12  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
13  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
14  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
15  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
16  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
17  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
18  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
19  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 37:: Java: JavaFX-Launcher
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c8fa0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c9120 ???
12  ???                           	       0x1111c95a0 ???
13  ???                           	       0x1111c9120 ???
14  ???                           	       0x1111c4154 ???
15  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
16  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
17  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
18  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
19  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
20  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
21  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
22  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
23  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 38:: Java: JNA Cleaner
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111a4b4c8 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 39:: CVDisplayLink
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b2408c0 _pthread_cond_wait + 1248
2   CoreVideo                     	       0x1946a43a4 CVDisplayLink::waitUntil(unsigned long long) + 316
3   CoreVideo                     	       0x1946a347c CVDisplayLink::runIOThread() + 504
4   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
5   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 40:: Java: updater
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1044e4d1c JavaThread::sleep_nanos(long) + 224
4   libjvm.dylib                  	       0x1045a39c8 JVM_SleepNanos + 264
5   ???                           	       0x111aa8fe4 ???
6   ???                           	       0x111a3ccb4 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c95a0 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c4154 ???
11  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
12  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
13  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
14  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
15  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
16  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
17  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
18  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
19  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 41:: Java: process reaper (pid 4595)
0   libsystem_kernel.dylib        	       0x18b2065a0 __wait4 + 8
1   libjava.dylib                 	       0x102e95f68 Java_java_lang_ProcessHandleImpl_waitForProcessExit0 + 52
2   ???                           	       0x1111cc954 ???
3   ???                           	       0x1111c8fa0 ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 42:: Java: idle-timeout-task
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1048322d4 ObjectMonitor::wait(long, bool, JavaThread*) + 1308
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x11197dcdc ???
7   ???                           	       0x111a43bd0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 43:: Java: HTTP-Dispatcher
0   libsystem_kernel.dylib        	       0x18b20501c kevent + 8
1   libnio.dylib                  	       0x102f04d20 Java_sun_nio_ch_KQueue_poll + 96
2   ???                           	       0x111cfab70 ???
3   ???                           	       0x111d3e8fc ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 44:: Java: file watcher
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d68a34 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c4154 ???
9   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
10  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
11  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
12  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
13  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
14  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
15  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
16  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
17  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 45:: Java: FileSystemWatcher
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d68a34 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 46:: Java: terminal-view
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1044e4d1c JavaThread::sleep_nanos(long) + 224
4   libjvm.dylib                  	       0x1045a39c8 JVM_SleepNanos + 264
5   ???                           	       0x111aa8fe4 ???
6   ???                           	       0x111d17eb4 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 47:: Java: process reaper (pid 4596)
0   libsystem_kernel.dylib        	       0x18b2065a0 __wait4 + 8
1   libjava.dylib                 	       0x102e95f68 Java_java_lang_ProcessHandleImpl_waitForProcessExit0 + 52
2   ???                           	       0x1111cc954 ???
3   ???                           	       0x1111c8fa0 ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 48:: Java: process reaper (pid 4612)
0   libsystem_kernel.dylib        	       0x18b2065a0 __wait4 + 8
1   libjava.dylib                 	       0x102e95f68 Java_java_lang_ProcessHandleImpl_waitForProcessExit0 + 52
2   ???                           	       0x1111cc954 ???
3   ???                           	       0x1111c8fa0 ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 49:: Java: file downloader
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1044e4d1c JavaThread::sleep_nanos(long) + 224
4   libjvm.dylib                  	       0x1045a39c8 JVM_SleepNanos + 264
5   ???                           	       0x111aa8fe4 ???
6   ???                           	       0x1119fff94 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 50:: Java: Cleaner-0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111a4b4c8 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 51:: Java: G1 Conc#1
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 52:: Java: G1 Conc#2
0   libsystem_kernel.dylib        	       0x18b1feed0 semaphore_wait_trap + 8
1   libjvm.dylib                  	       0x1048e4588 OSXSemaphore::wait() + 24
2   libjvm.dylib                  	       0x104a5f01c WorkerThread::run() + 84
3   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
4   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
5   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
6   libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 53:: Java: http handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 54:: Java: http handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 55:: Java: http handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 56:: Java: http handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 57:: Java: http handler
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c9120 ???
7   ???                           	       0x1111c95a0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 58:: Java: AWT-Shutdown
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854700 PlatformEvent::park() + 120
3   libjvm.dylib                  	       0x1048322f4 ObjectMonitor::wait(long, bool, JavaThread*) + 1340
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x11197dcdc ???
7   ???                           	       0x111adcf04 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 59:: Java: AWT-EventQueue-0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111d60478 ???
6   ???                           	       0x1111c8f40 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c9120 ???
10  ???                           	       0x1111c9120 ???
11  ???                           	       0x1111c9120 ???
12  ???                           	       0x1111c4154 ???
13  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
14  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
15  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
16  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
17  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
18  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
19  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
20  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
21  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 60:
0   libsystem_pthread.dylib       	       0x18b23b0e8 start_wqthread + 0

Thread 61:
0   libsystem_pthread.dylib       	       0x18b23b0e8 start_wqthread + 0

Thread 62:
0   libsystem_pthread.dylib       	       0x18b23b0e8 start_wqthread + 0

Thread 63:
0   libsystem_pthread.dylib       	       0x18b23b0e8 start_wqthread + 0

Thread 64:: Java: ForkJoinPool-1-worker-48
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 65:: Java: ForkJoinPool-1-worker-49
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 66:: Java: process reaper (pid 55791)
0   libsystem_kernel.dylib        	       0x18b2065a0 __wait4 + 8
1   libjava.dylib                 	       0x102e95f68 Java_java_lang_ProcessHandleImpl_waitForProcessExit0 + 52
2   ???                           	       0x1111cc954 ???
3   ???                           	       0x1111c8fa0 ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 67:: Java: ForkJoinPool-1-worker-50
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d20 Parker::park(bool, long) + 492
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 68:: Java: ForkJoinPool-1-worker-51
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 69:: Java: ForkJoinPool-1-worker-52
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 70:: Java: ForkJoinPool-1-worker-53
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 71:: Java: ForkJoinPool-1-worker-54
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 72:: Java: ForkJoinPool-1-worker-55
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854d34 Parker::park(bool, long) + 512
3   libjvm.dylib                  	       0x1049dd008 Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long) + 328
4   ???                           	       0x111909f5c ???
5   ???                           	       0x111cf3fa4 ???
6   ???                           	       0x1111c4154 ???
7   libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
8   libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
9   libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
10  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
11  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
12  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
13  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
14  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
15  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 73:
0   libsystem_pthread.dylib       	       0x18b23b0e8 start_wqthread + 0

Thread 74:: Java: Timer-0
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854924 PlatformEvent::park_nanos(long) + 332
3   libjvm.dylib                  	       0x1048322d4 ObjectMonitor::wait(long, bool, JavaThread*) + 1308
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x11197dcdc ???
7   ???                           	       0x111a43bd0 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 75:: Java: dnd
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x104854700 PlatformEvent::park() + 120
3   libjvm.dylib                  	       0x1048322f4 ObjectMonitor::wait(long, bool, JavaThread*) + 1340
4   libjvm.dylib                  	       0x104977244 ObjectSynchronizer::wait(Handle, long, JavaThread*) + 300
5   libjvm.dylib                  	       0x10458fd2c JVM_MonitorWait + 440
6   ???                           	       0x11197dcdc ???
7   ???                           	       0x1118efd4c ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 76:: Java: C1 CompilerThread1
0   libsystem_kernel.dylib        	       0x18b2026ec __psynch_cvwait + 8
1   libsystem_pthread.dylib       	       0x18b240894 _pthread_cond_wait + 1204
2   libjvm.dylib                  	       0x1048554b0 PlatformMonitor::wait(unsigned long long) + 272
3   libjvm.dylib                  	       0x104814750 Monitor::wait(unsigned long long) + 124
4   libjvm.dylib                  	       0x1042bc168 CompileQueue::get(CompilerThread*) + 556
5   libjvm.dylib                  	       0x1042bf930 CompileBroker::compiler_thread_loop() + 752
6   libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
7   libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
8   libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
9   libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
10  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8

Thread 77:: Java: process reaper (pid 55861)
0   libsystem_kernel.dylib        	       0x18b2065a0 __wait4 + 8
1   libjava.dylib                 	       0x102e95f68 Java_java_lang_ProcessHandleImpl_waitForProcessExit0 + 52
2   ???                           	       0x1111cc954 ???
3   ???                           	       0x1111c8fa0 ???
4   ???                           	       0x1111c95a0 ???
5   ???                           	       0x1111c9120 ???
6   ???                           	       0x1111c95a0 ???
7   ???                           	       0x1111c9120 ???
8   ???                           	       0x1111c9120 ???
9   ???                           	       0x1111c4154 ???
10  libjvm.dylib                  	       0x1044cdcb0 JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 984
11  libjvm.dylib                  	       0x1044ccbe8 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 328
12  libjvm.dylib                  	       0x1044cccb4 JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 100
13  libjvm.dylib                  	       0x1045a3690 thread_entry(JavaThread*, JavaThread*) + 156
14  libjvm.dylib                  	       0x1044e1a40 JavaThread::thread_main_inner() + 152
15  libjvm.dylib                  	       0x1049a760c Thread::call_run() + 200
16  libjvm.dylib                  	       0x10484ce68 thread_native_entry(Thread*) + 280
17  libsystem_pthread.dylib       	       0x18b2402e4 _pthread_start + 136
18  libsystem_pthread.dylib       	       0x18b23b0fc thread_start + 8


Thread 0 crashed with ARM Thread State (64-bit):
    x0: 0x0000000000000000   x1: 0x0000000000000000   x2: 0x0000000000000000   x3: 0xfffffffffffffffa
    x4: 0x000000018b648095   x5: 0x000000018b6480ab   x6: 0x0000000000000030   x7: 0x000000000000008d
    x8: 0x000000018b6487e3   x9: 0x00000001f504c000  x10: 0x0000600001e44028  x11: 0x00000000000082c3
   x12: 0x0000000000000000  x13: 0x0000000000000002  x14: 0x0000000000000000  x15: 0x0000000075ab6630
   x16: 0x000000029d56abbc  x17: 0x00000001fd1ef118  x18: 0x0000000000000000  x19: 0x000000013df05ab0
   x20: 0x000000013df05ac0  x21: 0x0000000000000001  x22: 0x0000600001e44000  x23: 0x0000600001e44010
   x24: 0x000000013d8df000  x25: 0x3f847ae147ae147b  x26: 0x00001f0001ca87e0  x27: 0x0000000000000000
   x28: 0x000000012e83cc00   fp: 0x000000016cf1d330   lr: 0x000000018b326828
    sp: 0x000000016cf1d2b0   pc: 0x000000018b494b98 cpsr: 0x60001000
   far: 0x0000000000000000  esr: 0xf2000001 (Breakpoint) brk 1

Binary Images:
       0x102d1c000 -        0x102d2ffff io.xpipe.app (15.3) <8d2b8695-ec87-3d95-9387-4b1ab37ee7cb> /Applications/XPipe.app/Contents/MacOS/xpiped
       0x102dd4000 -        0x102de7fff libjli.dylib (*) <8f442ec8-6444-3e61-afd2-3fa07edd503e> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjli.dylib
       0x10401c000 -        0x104bbffff libjvm.dylib (*) <f806d0b0-3c61-3018-b6b6-e7754a96fa06> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/server/libjvm.dylib
       0x102dfc000 -        0x102dfffff libjimage.dylib (*) <ee867993-0a7d-345d-9d46-73ec3b15e7d7> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjimage.dylib
       0x102e38000 -        0x102e4ffff libzip.dylib (*) <0ecbeba6-b0a4-3efa-808e-f74d9d220aca> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libzip.dylib
       0x102e90000 -        0x102ea3fff libjava.dylib (*) <908d9c2c-e617-3250-b950-e50547d03a04> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjava.dylib
       0x149800000 -        0x14a84ffff libjvmcicompiler.dylib (*) <25448dda-832e-37c0-918c-6a52712fcf74> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjvmcicompiler.dylib
       0x102f00000 -        0x102f0bfff libnio.dylib (*) <be999468-858f-3bb3-a96a-25fd73cf6ab5> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libnio.dylib
       0x102e78000 -        0x102e7ffff libnet.dylib (*) <5ae991a4-ea4c-3ba8-bdcb-9c8ce35ba9e8> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libnet.dylib
       0x103f80000 -        0x103f8bfff libverify.dylib (*) <99a1d584-42cf-3348-b1cf-64ea6190a338> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libverify.dylib
       0x12f980000 -        0x12f9e3fff libawt.dylib (*) <52290dd5-ba7e-3054-a877-0cd4ef655e50> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libawt.dylib
       0x11f51c000 -        0x11f57ffff libmlib_image.dylib (*) <7e8f92cd-0695-30fb-a938-78c00b27ed7d> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libmlib_image.dylib
       0x12fb64000 -        0x12fc1bfff libawt_lwawt.dylib (*) <6206de38-d471-3ff3-aa37-d078f25ee3f9> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libawt_lwawt.dylib
       0x103fcc000 -        0x103fd3fff libosxapp.dylib (*) <426bedde-c0f2-3214-bca0-f89b16bc10e6> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libosxapp.dylib
       0x12fdc4000 -        0x12feb7fff libfontmanager.dylib (*) <d2b8109a-eb61-3521-bbd7-cb20560e76c8> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libfontmanager.dylib
       0x12fc94000 -        0x12fd0ffff libfreetype.dylib (*) <a60a2ade-6d23-3ef7-869a-6cafb6844ff5> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libfreetype.dylib
       0x12d3dc000 -        0x12d3e7fff libobjc-trampolines.dylib (*) <3d687e9b-e092-3632-bc1d-74b19d492de0> /usr/lib/libobjc-trampolines.dylib
       0x14db18000 -        0x14e243fff com.apple.AGXMetalG14X (324.6) <da4fd60f-fe41-3f17-9e23-c9718a8013a3> /System/Library/Extensions/AGXMetalG14X.bundle/Contents/MacOS/AGXMetalG14X
       0x12fd50000 -        0x12fd57fff libprism_es2.dylib (*) <be77fda4-dcaa-368e-82de-bba731d9e862> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libprism_es2.dylib
       0x139f64000 -        0x139fcbfff com.apple.AppleMetalOpenGLRenderer (1.0) <a969aeaf-d20c-3296-b195-742e2b280d5e> /System/Library/Extensions/AppleMetalOpenGLRenderer.bundle/Contents/MacOS/AppleMetalOpenGLRenderer
       0x13d890000 -        0x13d8d3fff libglass.dylib (*) <1c76b2bf-dbea-308b-97d6-905a360d35d8> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libglass.dylib
       0x12fda4000 -        0x12fdabfff libjavafx_font.dylib (*) <97f441d4-6d1e-32f0-a46a-b7a4d2317b93> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjavafx_font.dylib
       0x14bf98000 -        0x14bfb3fff libjnidispatch.jnilib (*) <7dd28c5c-989e-3bd1-ac2e-38b6e8e40a97> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libjnidispatch.jnilib
       0x13ddec000 -        0x13ddeffff libxpipe_bridge.dylib (*) <ce731169-f959-3cea-a399-f55237ba667e> /Applications/XPipe.app/Contents/runtime/Contents/Home/lib/libxpipe_bridge.dylib
       0x18b2ab000 -        0x18b79ffff com.apple.CoreFoundation (6.9) <190e6a36-fcaa-3ea3-94bb-7009c44653da> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x18c49d000 -        0x18d2e4fff com.apple.Foundation (6.9) <16d282d0-8b48-3e76-8036-fcb45dece518> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
               0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ???
       0x18b1fe000 -        0x18b238ff7 libsystem_kernel.dylib (*) <eee9d0d3-dffc-37cb-9ced-b27cd0286d8c> /usr/lib/system/libsystem_kernel.dylib
       0x18b239000 -        0x18b245fff libsystem_pthread.dylib (*) <642faf7a-874e-37e6-8aba-2b0cc09a3025> /usr/lib/system/libsystem_pthread.dylib
       0x18b246000 -        0x18b272ffb libdyld.dylib (*) <c0c53058-94d2-3d9e-9e92-56ba8b43c327> /usr/lib/system/libdyld.dylib
       0x18ee63000 -        0x19029ffff com.apple.AppKit (6.9) <b88a44c1-d617-33dc-90ed-b6ab417c428e> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
       0x1946a1000 -        0x194701fff com.apple.CoreVideo (1.8) <0fcfe924-013c-3974-9fdf-58f9a8d71845> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=1.6G resident=0K(0%) swapped_out_or_unallocated=1.6G(100%)
Writable regions: Total=3.0G written=1446K(0%) resident=1446K(0%) swapped_out=0K(0%) unallocated=3.0G(100%)

                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate framework               128K        1 
Activity Tracing                   256K        1 
CG image                           288K        9 
ColorSync                          608K       30 
CoreAnimation                      400K       20 
CoreGraphics                        32K        2 
CoreImage                           64K        4 
CoreUI image data                 1776K       12 
Foundation                          16K        1 
Kernel Alloc Once                   32K        1 
MALLOC                             2.1G       74 
MALLOC guard page                  288K       18 
OpenGL GLSL                        256K        3 
STACK GUARD                       2944K       78 
Stack                            146.9M       78 
Stack Guard                       56.8M       52 
VM_ALLOCATE                        5.3G      678 
VM_ALLOCATE (reserved)           180.4M        8         reserved VM address space (unallocated)
__AUTH                            5135K      658 
__AUTH_CONST                      69.3M      900 
__CTF                               824        1 
__DATA                            44.7M      905 
__DATA_CONST                      24.8M      931 
__DATA_DIRTY                      2755K      334 
__FONT_DATA                        2352        1 
__GLSLBUILTINS                    5174K        1 
__INFO_FILTER                         8        1 
__LINKEDIT                       616.0M       25 
__OBJC_RW                         2374K        1 
__TEXT                             1.0G      951 
__TPRO_CONST                       272K        2 
mapped file                      441.0M       93 
owned unmapped memory              496K        1 
page table in kernel              1446K        1 
shared memory                      912K       17 
===========                     =======  ======= 
TOTAL                             10.0G     5893 
TOTAL, minus reserved VM space     9.8G     5893 



-----------
Full Report
-----------

{"app_name":"xpiped","timestamp":"2025-03-07 05:03:11.00 -0500","app_version":"15.3","slice_uuid":"8d2b8695-ec87-3d95-9387-4b1ab37ee7cb","build_version":"15.3","platform":1,"bundleID":"io.xpipe.app","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 15.3.1 (24D70)","roots_installed":0,"name":"xpiped","incident_id":"21C3376D-5CAC-4406-8AFA-10ED4ECB015D"}
{
  "uptime" : 33000,
  "procRole" : "Foreground",
  "version" : 2,
  "userID" : 501,
  "deployVersion" : 210,
  "modelCode" : "Mac14,10",
  "coalitionID" : 1006,
  "osVersion" : {
    "train" : "macOS 15.3.1",
    "build" : "24D70",
    "releaseType" : "User"
  },
  "captureTime" : "2025-03-07 05:03:02.0359 -0500",
  "codeSigningMonitor" : 1,
  "incident" : "21C3376D-5CAC-4406-8AFA-10ED4ECB015D",
  "pid" : 4582,
  "translated" : false,
  "cpuType" : "ARM-64",
  "roots_installed" : 0,
  "bug_type" : "309",
  "procLaunch" : "2025-03-04 20:49:07.3656 -0500",
  "procStartAbsTime" : 9896337206,
  "procExitAbsTime" : 806780184742,
  "procName" : "xpiped",
  "procPath" : "\/Applications\/XPipe.app\/Contents\/MacOS\/xpiped",
  "bundleInfo" : {"CFBundleShortVersionString":"15.3","CFBundleVersion":"15.3","CFBundleIdentifier":"io.xpipe.app"},
  "storeInfo" : {"deviceIdentifierForVendor":"540CED29-5B6E-536F-B24E-4C93EAE579B6","thirdParty":true},
  "parentProc" : "launchd",
  "parentPid" : 1,
  "coalitionName" : "io.xpipe.app",
  "crashReporterKey" : "7DF0C6D2-9B21-B647-8359-B8BFCA84AD12",
  "codeSigningID" : "io.xpipe.app",
  "codeSigningTeamID" : "PF6V9HYACS",
  "codeSigningFlags" : 570491649,
  "codeSigningValidationCategory" : 6,
  "codeSigningTrustLevel" : 4294967295,
  "instructionByteStream" : {"beforePC":"IAAg1KgNAJAIXR2Ryd00kCgpBvkgACDUqA0AkAiNH5HJ3TSQKCkG+Q==","atPC":"IAAg1KgNAJAIYSWRyd00kCgpBvkgACDUqA0AkAgZB5HJ3TSQKCkG+Q=="},
  "bootSessionUUID" : "F45BF7B0-93B1-43D2-8FEF-8D550316B265",
  "wakeTime" : 299,
  "sleepWakeUUID" : "29F56F1C-40A0-4598-A9E6-CF9D1506B168",
  "sip" : "enabled",
  "exception" : {"codes":"0x0000000000000001, 0x000000018b494b98","rawCodes":[1,6631803800],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
  "termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace\/BPT trap: 5","byProc":"exc handler","byPid":4582},
  "os_fault" : {"process":"xpiped"},
  "asi" : {"CoreFoundation":["Too many nested CFRunLoopRuns"]},
  "extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
  "faultingThread" : 0,
  "threads" : [{"triggered":true,"id":33475,"threadState":{"x":[{"value":0},{"value":0},{"value":0},{"value":18446744073709551610},{"value":6633586837,"symbolLocation":3721,"symbol":"_XMLPlistAppendDataUsingBase64.__CFPLDataEncodeTable"},{"value":6633586859,"symbolLocation":3743,"symbol":"_XMLPlistAppendDataUsingBase64.__CFPLDataEncodeTable"},{"value":48},{"value":141},{"value":6633588707,"symbolLocation":5591,"symbol":"_XMLPlistAppendDataUsingBase64.__CFPLDataEncodeTable"},{"value":8405696512,"symbolLocation":6088,"symbol":"__last_exception_backtrace__"},{"value":105553148002344},{"value":33475},{"value":0},{"value":2},{"value":0},{"value":1974167088},{"value":11229637564},{"value":8541630744},{"value":0},{"value":5334129328},{"value":5334129344},{"value":1},{"value":105553148002304},{"value":105553148002320},{"value":5327679488},{"value":4576918229304087675},{"value":34084890511328},{"value":0},{"value":5075356672}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6630303784},"cpsr":{"value":1610616832},"fp":{"value":6122754864},"sp":{"value":6122754736},"esr":{"value":4060086273,"description":"(Breakpoint) brk 1"},"pc":{"value":6631803800,"matchesCrashFrame":1},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":2005912,"symbol":"CFRunLoopRunSpecific.cold.1","symbolLocation":16,"imageIndex":24},{"imageOffset":505896,"symbol":"CFRunLoopRunSpecific","symbolLocation":832,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24},{"imageOffset":514104,"symbol":"__CFRunLoopDoSource0","symbolLocation":176,"imageIndex":24},{"imageOffset":513436,"symbol":"__CFRunLoopDoSources0","symbolLocation":244,"imageIndex":24},{"imageOffset":508216,"symbol":"__CFRunLoopRun","symbolLocation":840,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":369944,"symbol":"-[NSRunLoop(NSRunLoop) runMode:beforeDate:]","symbolLocation":212,"imageIndex":25},{"imageOffset":46084,"imageIndex":20},{"imageOffset":48952,"symbol":"Java_com_sun_glass_ui_mac_MacApplication__1enterNestedEventLoopImpl","symbolLocation":56,"imageIndex":20},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4475621232,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":5423952,"symbol":"jni_invoke_static(JNIEnv_*, JavaValue*, _jobject*, JNICallType, _jmethodID*, JNI_ArgumentPusher*, JavaThread*)","symbolLocation":368,"imageIndex":2},{"imageOffset":5438796,"symbol":"jni_CallStaticVoidMethod","symbolLocation":276,"imageIndex":2},{"imageOffset":37396,"imageIndex":20},{"imageOffset":493472,"symbol":"__NSThreadPerformPerform","symbolLocation":264,"imageIndex":25},{"imageOffset":514212,"symbol":"__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__","symbolLocation":28,"imageIndex":24}]},{"id":33482,"frames":[{"imageOffset":11436,"symbol":"__ulock_wait","symbolLocation":8,"imageIndex":27},{"imageOffset":38868,"symbol":"_pthread_join","symbolLocation":612,"imageIndex":28},{"imageOffset":54664,"symbol":"CallJavaMainInNewThread","symbolLocation":184,"imageIndex":1},{"imageOffset":49688,"symbol":"ContinueInNewThread","symbolLocation":148,"imageIndex":1},{"imageOffset":39988,"symbol":"JLI_Launch","symbolLocation":5632,"imageIndex":1},{"imageOffset":49284,"symbol":"jvmLauncherStartJvm","symbolLocation":328,"imageIndex":0},{"imageOffset":43652,"symbol":"Jvm::launch()","symbolLocation":716,"imageIndex":0},{"imageOffset":64944,"symbol":"app::launch(std::nothrow_t const&, void (*)(), LogAppender*)","symbolLocation":236,"imageIndex":0},{"imageOffset":56932,"symbol":"apple_main","symbolLocation":88,"imageIndex":1},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}],"threadState":{"x":[{"value":18446744073709551612},{"value":0},{"value":4867},{"value":0},{"value":150997247},{"value":3},{"value":0},{"value":0},{"value":4867},{"value":16908290},{"value":17},{"value":0},{"value":8400908040,"symbolLocation":0,"symbol":"vm_page_size"},{"value":1},{"value":4294967046},{"value":2043},{"value":515},{"value":8541643616},{"value":0},{"value":6127300608},{"value":2},{"value":6127300660},{"value":16908290},{"value":6125170912},{"value":8400912452,"symbolLocation":0,"symbol":"_pthread_list_lock"},{"value":17},{"value":5360337416},{"value":5351968757},{"value":5360337416}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629369812},"cpsr":{"value":1073745920},"fp":{"value":6125164720},"sp":{"value":6125164624},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629100716},"far":{"value":0}}},{"id":33493,"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623152,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":144,"imageIndex":2},{"imageOffset":8357712,"symbol":"Monitor::wait(unsigned long long)","symbolLocation":124,"imageIndex":2},{"imageOffset":10060824,"symbol":"Threads::destroy_vm()","symbolLocation":108,"imageIndex":2},{"imageOffset":5507692,"symbol":"jni_DestroyJavaVM","symbolLocation":220,"imageIndex":2},{"imageOffset":43308,"symbol":"JavaMain","symbolLocation":1324,"imageIndex":1},{"imageOffset":54736,"symbol":"ThreadJavaMain","symbolLocation":12,"imageIndex":1},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}],"threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6127299896},{"value":0},{"value":256},{"value":1099511628034},{"value":1099511628034},{"value":256},{"value":0},{"value":1099511628032},{"value":305},{"value":8541643384},{"value":0},{"value":105553122893152},{"value":105553166932160},{"value":6127300832},{"value":0},{"value":0},{"value":0},{"value":1},{"value":256},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6127300016},"sp":{"value":6127299872},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}}},{"id":33494,"name":"Java: GC Thread#0","threadState":{"x":[{"value":14},{"value":32},{"value":5},{"value":68719460488},{"value":0},{"value":2},{"value":0},{"value":1000000},{"value":6129446584},{"value":5064647296},{"value":4294967295},{"value":72},{"value":4355685632},{"value":18691697672192},{"value":4608},{"value":512},{"value":18446744073709551580},{"value":105553140727808},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":5},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6129446560},"sp":{"value":6129446544},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33495,"name":"Java: G1 Main Marker","threadState":{"x":[{"value":260},{"value":0},{"value":8960},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6131592392},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":105553122887072},{"value":105553166927296},{"value":6131593440},{"value":0},{"value":0},{"value":8960},{"value":8961},{"value":9216},{"value":4375337489,"symbolLocation":0,"symbol":"UsePerfData"},{"value":6131592704}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6131592512},"sp":{"value":6131592368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623152,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":144,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":3909188,"symbol":"G1ConcurrentMarkThread::run_service()","symbolLocation":176,"imageIndex":2},{"imageOffset":2859768,"symbol":"ConcurrentGCThread::run()","symbolLocation":36,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33496,"name":"Java: G1 Conc#0","threadState":{"x":[{"value":14},{"value":105553137355584},{"value":0},{"value":4724015040},{"value":4723998848},{"value":1},{"value":0},{"value":1},{"value":6133739192},{"value":5064651680},{"value":4294967295},{"value":19791209304578},{"value":4608},{"value":19791209304576},{"value":376832},{"value":376832},{"value":18446744073709551580},{"value":105553140728096},{"value":0},{"value":105553166938680},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":2},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166938664},{"value":105553166938676},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6133739168},"sp":{"value":6133739152},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33497,"name":"Java: G1 Refine#0","threadState":{"x":[{"value":260},{"value":0},{"value":48229120},{"value":0},{"value":0},{"value":160},{"value":0},{"value":112000000},{"value":6135884936},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":105553122932800},{"value":105553166984640},{"value":6135886048},{"value":112000000},{"value":0},{"value":48229120},{"value":48230145},{"value":48230400},{"value":4375557616,"symbolLocation":0,"symbol":"SuspendibleThreadSet::_suspend_all"},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6135885056},"sp":{"value":6135884912},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":3945348,"symbol":"G1PrimaryConcurrentRefineThread::wait_for_completed_buffers()","symbolLocation":68,"imageIndex":2},{"imageOffset":3944168,"symbol":"G1ConcurrentRefineThread::run_service()","symbolLocation":144,"imageIndex":2},{"imageOffset":2859768,"symbol":"ConcurrentGCThread::run()","symbolLocation":36,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33498,"name":"Java: G1 Service","threadState":{"x":[{"value":260},{"value":0},{"value":8515328},{"value":0},{"value":0},{"value":160},{"value":0},{"value":626000000},{"value":6138031448},{"value":0},{"value":256},{"value":1099511628034},{"value":1099511628034},{"value":256},{"value":0},{"value":1099511628032},{"value":305},{"value":8541643384},{"value":0},{"value":105553122933040},{"value":105553166984960},{"value":6138032352},{"value":626000000},{"value":0},{"value":8515328},{"value":8515329},{"value":8515584},{"value":33203440999875},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6138031568},"sp":{"value":6138031424},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":4257856,"symbol":"G1ServiceThread::wait_for_task()","symbolLocation":120,"imageIndex":2},{"imageOffset":4258604,"symbol":"G1ServiceThread::run_service()","symbolLocation":44,"imageIndex":2},{"imageOffset":2859768,"symbol":"ConcurrentGCThread::run()","symbolLocation":36,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33500,"name":"Java: VM Periodic Task Thread","threadState":{"x":[{"value":260},{"value":0},{"value":768},{"value":0},{"value":0},{"value":160},{"value":0},{"value":49999000},{"value":6140177736},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":105553122890832},{"value":105553166930304},{"value":6140178656},{"value":49999000},{"value":0},{"value":768},{"value":164308993},{"value":164309248},{"value":4835703278458516699},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6140177856},"sp":{"value":6140177712},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":8445560,"symbol":"WatcherThread::sleep() const","symbolLocation":152,"imageIndex":2},{"imageOffset":8445780,"symbol":"WatcherThread::run()","symbolLocation":60,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33501,"name":"Java: VM Thread","threadState":{"x":[{"value":260},{"value":0},{"value":9136128},{"value":0},{"value":0},{"value":160},{"value":0},{"value":999999000},{"value":6142324024},{"value":0},{"value":7168},{"value":30786325584898},{"value":30786325584898},{"value":7168},{"value":0},{"value":30786325584896},{"value":305},{"value":8541643384},{"value":0},{"value":105553122893632},{"value":105553166932544},{"value":6142324960},{"value":999999000},{"value":0},{"value":9136128},{"value":9136129},{"value":9136384},{"value":4375337072,"symbolLocation":0,"symbol":"GuaranteedSafepointInterval"},{"value":4375519866,"symbolLocation":0,"symbol":"HandshakeALot"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6142324144},"sp":{"value":6142324000},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":10581476,"symbol":"VMThread::wait_for_operation()","symbolLocation":444,"imageIndex":2},{"imageOffset":10577764,"symbol":"VMThread::run()","symbolLocation":188,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33504,"name":"Java: Reference Handler","threadState":{"x":[{"value":260},{"value":0},{"value":30208},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6145615832},{"value":0},{"value":3584},{"value":15393162792450},{"value":15393162792450},{"value":3584},{"value":0},{"value":15393162792448},{"value":305},{"value":8541643384},{"value":0},{"value":105553122893312},{"value":105553166932288},{"value":6145618144},{"value":0},{"value":0},{"value":30208},{"value":30209},{"value":30464},{"value":0},{"value":5066828288}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6145615952},"sp":{"value":6145615808},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623152,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":144,"imageIndex":2},{"imageOffset":8357712,"symbol":"Monitor::wait(unsigned long long)","symbolLocation":124,"imageIndex":2},{"imageOffset":5806740,"symbol":"JVM_WaitForReferencePendingList","symbolLocation":200,"imageIndex":2},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4489550756,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33505,"name":"Java: Finalizer","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6147761272},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5362448424},{"value":5362448488},{"value":6147764448},{"value":0},{"value":0},{"value":0},{"value":1},{"value":256},{"value":105553122941184},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6147761392},"sp":{"value":6147761248},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8619776,"symbol":"PlatformEvent::park()","symbolLocation":120,"imageIndex":2},{"imageOffset":8479476,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1340,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33506,"name":"Java: Signal Dispatcher","threadState":{"x":[{"value":14},{"value":29955},{"value":29955},{"value":29955},{"value":15530601742336},{"value":112163070935040},{"value":44},{"value":0},{"value":10},{"value":4376030432,"symbolLocation":128,"symbol":"_MergedGlobals"},{"value":4294967295},{"value":17},{"value":17},{"value":5064690256},{"value":4294967295},{"value":0},{"value":18446744073709551580},{"value":105553140729392},{"value":0},{"value":105553157489136},{"value":5067438592},{"value":105553157489136},{"value":4376030304,"symbolLocation":0,"symbol":"_MergedGlobals"},{"value":105553122963728},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":2},{"value":4},{"value":6},{"value":5067439700}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":1610616832},"fp":{"value":6149909520},"sp":{"value":6149909504},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":9299120,"symbol":"os::signal_wait()","symbolLocation":180,"imageIndex":2},{"imageOffset":8567080,"symbol":"signal_thread_entry(JavaThread*, JavaThread*)","symbolLocation":76,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33507,"name":"Java: Service Thread","threadState":{"x":[{"value":260},{"value":0},{"value":43264},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6152055944},{"value":0},{"value":256},{"value":1099511628034},{"value":1099511628034},{"value":256},{"value":0},{"value":1099511628032},{"value":305},{"value":8541643384},{"value":0},{"value":105553122888352},{"value":105553166928320},{"value":6152057056},{"value":0},{"value":0},{"value":43264},{"value":43265},{"value":43520},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6152056064},"sp":{"value":6152055920},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623152,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":144,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":9214780,"symbol":"ServiceThread::service_thread_entry(JavaThread*, JavaThread*)","symbolLocation":508,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33508,"name":"Java: Monitor Deflation Thread","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":250000000},{"value":6154202392},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":105553122888272},{"value":105553166928256},{"value":6154203360},{"value":250000000},{"value":0},{"value":0},{"value":33555201},{"value":33555456},{"value":4375553704,"symbolLocation":0,"symbol":"SafepointSynchronize::_state"},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6154202512},"sp":{"value":6154202368},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":8312308,"symbol":"MonitorDeflationThread::monitor_deflation_thread_entry(JavaThread*, JavaThread*)","symbolLocation":252,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33509,"name":"Java: JVMCI-native CompilerThread0","threadState":{"x":[{"value":4},{"value":0},{"value":11428864},{"value":105553122889952},{"value":30794022166292224},{"value":4256},{"value":0},{"value":999999000},{"value":6158445304},{"value":7169792},{"value":7169792},{"value":30792922654664450},{"value":30792922654664450},{"value":7169792},{"value":256},{"value":30794022166292224},{"value":305},{"value":8541643384},{"value":0},{"value":105553122889952},{"value":105553166929600},{"value":6158446816},{"value":999999000},{"value":0},{"value":11428864},{"value":11428866},{"value":11429120},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4375322624,"symbolLocation":32,"symbol":"OopOopIterateBoundedDispatch<VerifyCleanCardClosure>::_table"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6158445424},"sp":{"value":6158445280},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357712,"symbol":"Monitor::wait(unsigned long long)","symbolLocation":124,"imageIndex":2},{"imageOffset":5919328,"symbol":"JVMCICompiler::on_empty_queue(CompileQueue*, CompilerThread*)","symbolLocation":128,"imageIndex":2},{"imageOffset":2752852,"symbol":"CompileQueue::get(CompilerThread*)","symbolLocation":536,"imageIndex":2},{"imageOffset":2767152,"symbol":"CompileBroker::compiler_thread_loop()","symbolLocation":752,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33510,"name":"Java: C1 CompilerThread0","threadState":{"x":[{"value":5269337856},{"value":5086023936},{"value":4362749376,"symbolLocation":0,"symbol":"Assembler::b(unsigned char*)"},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":4294967295},{"value":6162687000},{"value":287607460},{"value":1828},{"value":0},{"value":5086951368},{"value":32},{"value":2043},{"value":72},{"value":105553140695184},{"value":0},{"value":5269337856},{"value":6162684072},{"value":4373784947},{"value":5087716744},{"value":0},{"value":192},{"value":105553136112096},{"value":105553117673344},{"value":3},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4363803092},"cpsr":{"value":536875008},"fp":{"value":6162683888},"sp":{"value":6162683856},"esr":{"value":2449473611,"description":"(Data Abort) byte write Access flag fault"},"pc":{"value":4363418028},"far":{"value":0}},"frames":[{"imageOffset":1227180,"symbol":"AbstractAssembler::bind(Label&)","symbolLocation":36,"imageIndex":2},{"imageOffset":1612244,"symbol":"LIR_Assembler::emit_opLabel(LIR_OpLabel*)","symbolLocation":28,"imageIndex":2},{"imageOffset":1609812,"symbol":"LIR_Assembler::emit_lir_list(LIR_List*)","symbolLocation":156,"imageIndex":2},{"imageOffset":1609980,"symbol":"LIR_Assembler::emit_code(BlockList*)","symbolLocation":116,"imageIndex":2},{"imageOffset":1428720,"symbol":"Compilation::emit_code_body()","symbolLocation":220,"imageIndex":2},{"imageOffset":1431216,"symbol":"Compilation::compile_java_method()","symbolLocation":648,"imageIndex":2},{"imageOffset":1431868,"symbol":"Compilation::compile_method()","symbolLocation":368,"imageIndex":2},{"imageOffset":1432644,"symbol":"Compilation::Compilation(AbstractCompiler*, ciEnv*, ciMethod*, int, BufferBlob*, bool, DirectiveSet*)","symbolLocation":372,"imageIndex":2},{"imageOffset":1438892,"symbol":"Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)","symbolLocation":92,"imageIndex":2},{"imageOffset":2769084,"symbol":"CompileBroker::invoke_compiler_on_method(CompileTask*)","symbolLocation":1216,"imageIndex":2},{"imageOffset":2767368,"symbol":"CompileBroker::compiler_thread_loop()","symbolLocation":968,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33512,"name":"Java: Common-Cleaner","threadState":{"x":[{"value":260},{"value":0},{"value":150272},{"value":0},{"value":0},{"value":160},{"value":59},{"value":999999959},{"value":6169076856},{"value":0},{"value":256},{"value":1099511628034},{"value":1099511628034},{"value":256},{"value":0},{"value":1099511628032},{"value":305},{"value":8541643384},{"value":0},{"value":5511452640},{"value":5511452704},{"value":6169080032},{"value":999999959},{"value":59},{"value":150272},{"value":150273},{"value":150528},{"value":0},{"value":5511451136}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6169076976},"sp":{"value":6169076832},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4590974152,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33513,"name":"Java: Notification Thread","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6171225352},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":105553122888432},{"value":105553166928384},{"value":6171226336},{"value":0},{"value":0},{"value":0},{"value":1},{"value":256},{"value":0},{"value":4375518560,"symbolLocation":0,"symbol":"DCmdFactory::_has_pending_jmx_notification"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6171225472},"sp":{"value":6171225328},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623152,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":144,"imageIndex":2},{"imageOffset":8357564,"symbol":"Monitor::wait_without_safepoint_check(unsigned long long)","symbolLocation":48,"imageIndex":2},{"imageOffset":8447276,"symbol":"NotificationThread::notification_thread_entry(JavaThread*, JavaThread*)","symbolLocation":164,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33522,"name":"Java: referenceGC","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":999999000},{"value":6177613432},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":4828734760},{"value":4828734824},{"value":6177616096},{"value":999999000},{"value":0},{"value":0},{"value":8450817},{"value":8451072},{"value":4},{"value":6}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6177613552},"sp":{"value":6177613408},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":5016860,"symbol":"JavaThread::sleep_nanos(long)","symbolLocation":224,"imageIndex":2},{"imageOffset":5798344,"symbol":"JVM_SleepNanos","symbolLocation":264,"imageIndex":2},{"imageOffset":4591357924,"imageIndex":26},{"imageOffset":4590914740,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33548,"name":"Java: GC Thread#1","threadState":{"x":[{"value":14},{"value":32},{"value":3},{"value":68719460488},{"value":0},{"value":6},{"value":563048741535767},{"value":21673573217468416},{"value":6189493944},{"value":5063606656},{"value":4294967295},{"value":72},{"value":4355682816},{"value":17592186044416},{"value":4608},{"value":768},{"value":18446744073709551580},{"value":105553140829568},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":3},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6189493920},"sp":{"value":6189493904},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33549,"name":"Java: GC Thread#2","threadState":{"x":[{"value":14},{"value":32},{"value":0},{"value":68719460488},{"value":0},{"value":4},{"value":0},{"value":1000000},{"value":6191640248},{"value":5060690928},{"value":4294967295},{"value":72},{"value":4355195648},{"value":19791209299968},{"value":4608},{"value":256},{"value":18446744073709551580},{"value":105553140795648},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":0},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6191640224},"sp":{"value":6191640208},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33550,"name":"Java: GC Thread#3","threadState":{"x":[{"value":14},{"value":32},{"value":1},{"value":68719460488},{"value":0},{"value":3},{"value":0},{"value":999000},{"value":6193786552},{"value":5060691856},{"value":4294967295},{"value":72},{"value":4355682304},{"value":2816},{"value":512},{"value":0},{"value":18446744073709551580},{"value":105553140795792},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":1},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6193786528},"sp":{"value":6193786512},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33552,"name":"Java: GC Thread#4","threadState":{"x":[{"value":14},{"value":32},{"value":8},{"value":68719460488},{"value":35},{"value":8},{"value":0},{"value":999000},{"value":6195932856},{"value":4828791616},{"value":4294967295},{"value":72},{"value":5334122436},{"value":39},{"value":5334106112},{"value":2428251249},{"value":18446744073709551580},{"value":105553140796080},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":8},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6195932832},"sp":{"value":6195932816},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33553,"name":"Java: GC Thread#5","threadState":{"x":[{"value":14},{"value":32},{"value":7},{"value":68719460488},{"value":4},{"value":4020300035},{"value":105553155366976},{"value":16159230116068710345},{"value":6198079160},{"value":4828792544},{"value":4294967295},{"value":72},{"value":4355681280},{"value":5361412064},{"value":5361412064},{"value":2043},{"value":18446744073709551580},{"value":105553140796224},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":7},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6198079136},"sp":{"value":6198079120},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33554,"name":"Java: GC Thread#6","threadState":{"x":[{"value":14},{"value":32},{"value":6},{"value":68719460488},{"value":35},{"value":7},{"value":0},{"value":999000},{"value":6200225464},{"value":4828793936},{"value":4294967295},{"value":72},{"value":4294967293},{"value":15393162788864},{"value":4608},{"value":1280},{"value":18446744073709551580},{"value":105553140796368},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":6},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6200225440},"sp":{"value":6200225424},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33555,"name":"Java: GC Thread#7","threadState":{"x":[{"value":14},{"value":32},{"value":4},{"value":68719460488},{"value":0},{"value":1},{"value":0},{"value":999000},{"value":6202371768},{"value":4828795328},{"value":4294967295},{"value":72},{"value":4355683072},{"value":128},{"value":131072},{"value":0},{"value":18446744073709551580},{"value":105553140796512},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":4},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6202371744},"sp":{"value":6202371728},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33556,"name":"Java: GC Thread#8","threadState":{"x":[{"value":14},{"value":1},{"value":9},{"value":68719460488},{"value":35},{"value":9},{"value":0},{"value":999000},{"value":6204518072},{"value":4828797728},{"value":4294967295},{"value":72},{"value":2816},{"value":2816},{"value":0},{"value":0},{"value":18446744073709551580},{"value":105553140796656},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":9},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":1610616832},"fp":{"value":6204518048},"sp":{"value":6204518032},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33557,"name":"Java: GC Thread#9","threadState":{"x":[{"value":14},{"value":32},{"value":2},{"value":68719460488},{"value":0},{"value":5},{"value":0},{"value":999000},{"value":6206664376},{"value":4828800128},{"value":4294967295},{"value":72},{"value":4355685376},{"value":2816},{"value":256},{"value":0},{"value":18446744073709551580},{"value":105553140796800},{"value":0},{"value":105553166937912},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":2},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166937896},{"value":105553166937908},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":6206664352},"sp":{"value":6206664336},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33562,"name":"com.apple.NSEventThread","threadState":{"x":[{"value":268451845},{"value":21592279046},{"value":8589934592},{"value":352956117417984},{"value":0},{"value":352956117417984},{"value":2},{"value":4294967295},{"value":18446744073709550527},{"value":2},{"value":0},{"value":0},{"value":0},{"value":82179},{"value":0},{"value":0},{"value":18446744073709551569},{"value":8541625848},{"value":0},{"value":4294967295},{"value":2},{"value":352956117417984},{"value":0},{"value":352956117417984},{"value":6207234152},{"value":8589934592},{"value":21592279046},{"value":21592279046},{"value":4412409862}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629168644},"cpsr":{"value":4096},"fp":{"value":6207234000},"sp":{"value":6207233920},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093204},"far":{"value":0}},"frames":[{"imageOffset":3924,"symbol":"mach_msg2_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":79364,"symbol":"mach_msg2_internal","symbolLocation":80,"imageIndex":27},{"imageOffset":39672,"symbol":"mach_msg_overwrite","symbolLocation":480,"imageIndex":27},{"imageOffset":4764,"symbol":"mach_msg","symbolLocation":24,"imageIndex":27},{"imageOffset":514636,"symbol":"__CFRunLoopServiceMachPort","symbolLocation":160,"imageIndex":24},{"imageOffset":508588,"symbol":"__CFRunLoopRun","symbolLocation":1212,"imageIndex":24},{"imageOffset":505652,"symbol":"CFRunLoopRunSpecific","symbolLocation":588,"imageIndex":24},{"imageOffset":1442424,"symbol":"_NSEventThread","symbolLocation":148,"imageIndex":30},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33563,"name":"Java: Java2D Queue Flusher","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":100000000},{"value":6209381928},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5362738728},{"value":5362738792},{"value":6209384672},{"value":100000000},{"value":0},{"value":0},{"value":82819585},{"value":82819840},{"value":105553123189104},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6209382048},"sp":{"value":6209381904},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":8479444,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1308,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4590132444,"imageIndex":26},{"imageOffset":4590859196,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33564,"name":"Java: Java2D Disposer","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6211527448},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5503364064},{"value":5503364128},{"value":6211530976},{"value":0},{"value":0},{"value":0},{"value":1},{"value":256},{"value":0},{"value":5503362560}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6211527568},"sp":{"value":6211527424},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052896,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33565,"name":"Java: QuantumRenderer-0","threadState":{"x":[{"value":260},{"value":0},{"value":480000},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6213674312},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5512259040},{"value":5512259104},{"value":6213677280},{"value":0},{"value":0},{"value":480000},{"value":480001},{"value":480256},{"value":0},{"value":5512257536}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6213674432},"sp":{"value":6213674288},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33567,"name":"Java: InvokeLaterDispatcher","threadState":{"x":[{"value":260},{"value":0},{"value":1003528960},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6215821096},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5075425248},{"value":5075425312},{"value":6215823584},{"value":0},{"value":0},{"value":1003528960},{"value":1003528961},{"value":1003529216},{"value":0},{"value":5075423744}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6215821216},"sp":{"value":6215821072},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33571,"name":"Java: Prism Font Disposer","threadState":{"x":[{"value":260},{"value":0},{"value":7168},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6220686680},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5512561632},{"value":5512561696},{"value":6220689632},{"value":0},{"value":0},{"value":7168},{"value":7169},{"value":7424},{"value":0},{"value":5512560128}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6220686800},"sp":{"value":6220686656},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33582,"name":"Java: app-wait","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6259630776},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5076493792},{"value":5076493856},{"value":6259634400},{"value":0},{"value":0},{"value":0},{"value":1},{"value":256},{"value":0},{"value":5076492288}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6259630896},"sp":{"value":6259630752},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33583,"name":"Java: VirtualThread-unparker","threadState":{"x":[{"value":260},{"value":0},{"value":4293376},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6261777640},{"value":0},{"value":1280},{"value":5497558140162},{"value":5497558140162},{"value":1280},{"value":0},{"value":5497558140160},{"value":305},{"value":8541643384},{"value":0},{"value":5076461536},{"value":5076461600},{"value":6261780704},{"value":0},{"value":0},{"value":4293376},{"value":4293633},{"value":4293888},{"value":0},{"value":5076460032}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6261777760},"sp":{"value":6261777616},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33584,"name":"Java: JavaFX-Launcher","threadState":{"x":[{"value":260},{"value":0},{"value":2560},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6263923512},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5268088800},{"value":5268088864},{"value":6263927008},{"value":0},{"value":0},{"value":2560},{"value":2561},{"value":2816},{"value":0},{"value":5268087296}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6263923632},"sp":{"value":6263923488},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33585,"name":"Java: JNA Cleaner","threadState":{"x":[{"value":260},{"value":0},{"value":256},{"value":0},{"value":0},{"value":160},{"value":29},{"value":999994750},{"value":6266070440},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5268155360},{"value":5268155424},{"value":6266073312},{"value":999994750},{"value":29},{"value":256},{"value":283393},{"value":283648},{"value":0},{"value":5268153856}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6266070560},"sp":{"value":6266070416},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4590974152,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33586,"name":"CVDisplayLink","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":65704},{"value":0},{"value":7382750},{"value":1005783809},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5268152376},{"value":5268152440},{"value":1},{"value":7382750},{"value":0},{"value":0},{"value":1005783809},{"value":1005784064},{"value":8364932344,"symbolLocation":0,"symbol":"CVHostTimeBase::sToNanosDenominator"},{"value":8364932376,"symbolLocation":0,"symbol":"kZeroVideoTime"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361856},"cpsr":{"value":2684358656},"fp":{"value":6216396208},"sp":{"value":6216396064},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30912,"symbol":"_pthread_cond_wait","symbolLocation":1248,"imageIndex":28},{"imageOffset":13220,"symbol":"CVDisplayLink::waitUntil(unsigned long long)","symbolLocation":316,"imageIndex":31},{"imageOffset":9340,"symbol":"CVDisplayLink::runIOThread()","symbolLocation":504,"imageIndex":31},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33588,"name":"Java: updater","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":3599},{"value":999999000},{"value":6268216920},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":4828965160},{"value":4828965224},{"value":6268219616},{"value":999999000},{"value":3599},{"value":0},{"value":2561},{"value":2816},{"value":4},{"value":6}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6268217040},"sp":{"value":6268216896},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":5016860,"symbol":"JavaThread::sleep_nanos(long)","symbolLocation":224,"imageIndex":2},{"imageOffset":5798344,"symbol":"JVM_SleepNanos","symbolLocation":264,"imageIndex":2},{"imageOffset":4591357924,"imageIndex":26},{"imageOffset":4590914740,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33609,"name":"Java: process reaper (pid 4595)","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":0},{"value":30214263728},{"value":31},{"value":2},{"value":48},{"value":4294967276},{"value":8400908032,"symbolLocation":0,"symbol":"errno"},{"value":4343815988,"symbolLocation":0,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0"},{"value":25},{"value":34084883122160},{"value":4828962832},{"value":16},{"value":34084887178496},{"value":7},{"value":8541643648},{"value":0},{"value":4595},{"value":1},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":0},{"value":4582062592},{"value":6226896728},{"value":6226898288},{"value":34084883120424},{"value":0},{"value":5276607488}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4343816040},"cpsr":{"value":1610616832},"fp":{"value":6226896544},"sp":{"value":6226896416},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629123488},"far":{"value":0}},"frames":[{"imageOffset":34208,"symbol":"__wait4","symbolLocation":8,"imageIndex":27},{"imageOffset":24424,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0","symbolLocation":52,"imageIndex":5},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33612,"name":"Java: idle-timeout-task","threadState":{"x":[{"value":260},{"value":0},{"value":256},{"value":0},{"value":0},{"value":160},{"value":9},{"value":999999000},{"value":6282995096},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5362812456},{"value":5362812520},{"value":6282997984},{"value":999999000},{"value":9},{"value":256},{"value":859649},{"value":859904},{"value":105553121758496},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6282995216},"sp":{"value":6282995072},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":8479444,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1308,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4590132444,"imageIndex":26},{"imageOffset":4590943184,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33613,"name":"Java: HTTP-Dispatcher","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":5512975360},{"value":256},{"value":6285141728},{"value":30101985176},{"value":18446744073707454464},{"value":1},{"value":0},{"value":1000000},{"value":6285142080},{"value":30101985176},{"value":9},{"value":0},{"value":0},{"value":363},{"value":30097093672},{"value":0},{"value":5068709312},{"value":6285142232},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":34084909955351},{"value":4582062592},{"value":0},{"value":6285143408},{"value":34084881440560},{"value":0},{"value":5068708352}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4344270112},"cpsr":{"value":1610616832},"fp":{"value":6285141760},"sp":{"value":6285141728},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629117980},"far":{"value":0}},"frames":[{"imageOffset":28700,"symbol":"kevent","symbolLocation":8,"imageIndex":27},{"imageOffset":19744,"symbol":"Java_sun_nio_ch_KQueue_poll","symbolLocation":96,"imageIndex":7},{"imageOffset":4593789808,"imageIndex":26},{"imageOffset":4594067708,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33619,"name":"Java: file watcher","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":9998959},{"value":6307309048},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5077111264},{"value":5077111328},{"value":6307311840},{"value":9998959},{"value":0},{"value":0},{"value":722305537},{"value":722305792},{"value":0},{"value":5077109760}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6307309168},"sp":{"value":6307309024},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594240052,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33621,"name":"Java: FileSystemWatcher","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":1},{"value":998775667},{"value":13227779352},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5068713952},{"value":5068714016},{"value":13227782368},{"value":998775667},{"value":1},{"value":0},{"value":4249601},{"value":4249856},{"value":0},{"value":5068712448}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13227779472},"sp":{"value":13227779328},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594240052,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33622,"name":"Java: terminal-view","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":499999000},{"value":13229925944},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5064917800},{"value":5064917864},{"value":13229928672},{"value":499999000},{"value":0},{"value":0},{"value":16865793},{"value":16866048},{"value":4},{"value":6}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13229926064},"sp":{"value":13229925920},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":5016860,"symbol":"JavaThread::sleep_nanos(long)","symbolLocation":224,"imageIndex":2},{"imageOffset":5798344,"symbol":"JVM_SleepNanos","symbolLocation":264,"imageIndex":2},{"imageOffset":4591357924,"imageIndex":26},{"imageOffset":4593909428,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33629,"name":"Java: process reaper (pid 4596)","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":0},{"value":30209874096},{"value":31},{"value":2},{"value":48},{"value":4294967276},{"value":8400908032,"symbolLocation":0,"symbol":"errno"},{"value":4343815988,"symbolLocation":0,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0"},{"value":25},{"value":34084883122160},{"value":5061071008},{"value":16},{"value":34084887178496},{"value":7},{"value":8541643648},{"value":0},{"value":4596},{"value":1},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":0},{"value":4582062592},{"value":6232352600},{"value":6232354160},{"value":34084883120424},{"value":0},{"value":5276749824}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4343816040},"cpsr":{"value":1610616832},"fp":{"value":6232352416},"sp":{"value":6232352288},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629123488},"far":{"value":0}},"frames":[{"imageOffset":34208,"symbol":"__wait4","symbolLocation":8,"imageIndex":27},{"imageOffset":24424,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0","symbolLocation":52,"imageIndex":5},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":33680,"name":"Java: process reaper (pid 4612)","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":0},{"value":30214497632},{"value":31},{"value":2},{"value":25},{"value":4294967276},{"value":8400908032,"symbolLocation":0,"symbol":"errno"},{"value":4343815988,"symbolLocation":0,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0"},{"value":25},{"value":34084883122160},{"value":5061067024},{"value":2147483647},{"value":34084887178496},{"value":7},{"value":8541643648},{"value":0},{"value":4612},{"value":1},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":0},{"value":4582062592},{"value":6232614744},{"value":6232616304},{"value":34084883120424},{"value":0},{"value":5512972800}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4343816040},"cpsr":{"value":1610616832},"fp":{"value":6232614560},"sp":{"value":6232614432},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629123488},"far":{"value":0}},"frames":[{"imageOffset":34208,"symbol":"__wait4","symbolLocation":8,"imageIndex":27},{"imageOffset":24424,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0","symbolLocation":52,"imageIndex":5},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":34095,"name":"Java: file downloader","threadState":{"x":[{"value":260},{"value":0},{"value":0},{"value":0},{"value":0},{"value":160},{"value":0},{"value":20000000},{"value":13281289784},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5061065256},{"value":5061065320},{"value":13281292512},{"value":20000000},{"value":0},{"value":0},{"value":387585793},{"value":387586048},{"value":4},{"value":6}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13281289904},"sp":{"value":13281289760},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":5016860,"symbol":"JavaThread::sleep_nanos(long)","symbolLocation":224,"imageIndex":2},{"imageOffset":5798344,"symbol":"JVM_SleepNanos","symbolLocation":264,"imageIndex":2},{"imageOffset":4591357924,"imageIndex":26},{"imageOffset":4590665620,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":34165,"name":"Java: Cleaner-0","threadState":{"x":[{"value":260},{"value":0},{"value":25600},{"value":0},{"value":0},{"value":160},{"value":59},{"value":999998958},{"value":6304064632},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5083927008},{"value":5083927072},{"value":6304067808},{"value":999998958},{"value":59},{"value":25600},{"value":141825},{"value":142080},{"value":0},{"value":5083925504}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6304064752},"sp":{"value":6304064608},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4590974152,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":34171,"name":"Java: G1 Conc#1","threadState":{"x":[{"value":14},{"value":1},{"value":0},{"value":4724080576},{"value":4724064384},{"value":1},{"value":0},{"value":1},{"value":13458190008},{"value":5065136288},{"value":4294967295},{"value":19791209304578},{"value":4608},{"value":19791209304576},{"value":381271},{"value":381271},{"value":18446744073709551580},{"value":105553140888368},{"value":0},{"value":105553166938680},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":0},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166938664},{"value":105553166938676},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":1610616832},"fp":{"value":13458189984},"sp":{"value":13458189968},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":34172,"name":"Java: G1 Conc#2","threadState":{"x":[{"value":14},{"value":105553137355584},{"value":0},{"value":4724047808},{"value":4724031616},{"value":1},{"value":0},{"value":1},{"value":13460336312},{"value":5061152960},{"value":4294967295},{"value":19791209304578},{"value":4608},{"value":19791209304576},{"value":380928},{"value":380928},{"value":18446744073709551580},{"value":105553140549168},{"value":0},{"value":105553166938680},{"value":4375459840,"symbolLocation":0,"symbol":"WorkerThread::_worker_id"},{"value":1},{"value":1},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4294967295},{"value":105553166938664},{"value":105553166938676},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4371400072},"cpsr":{"value":536875008},"fp":{"value":13460336288},"sp":{"value":13460336272},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629093072},"far":{"value":0}},"frames":[{"imageOffset":3792,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":27},{"imageOffset":9209224,"symbol":"OSXSemaphore::wait()","symbolLocation":24,"imageIndex":2},{"imageOffset":10760220,"symbol":"WorkerThread::run()","symbolLocation":84,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":36276,"name":"Java: http handler","threadState":{"x":[{"value":260},{"value":0},{"value":4096},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13259793848},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5077594080},{"value":5077594144},{"value":13259796704},{"value":0},{"value":0},{"value":4096},{"value":4097},{"value":4352},{"value":0},{"value":5077592576}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13259793968},"sp":{"value":13259793824},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":36281,"name":"Java: http handler","threadState":{"x":[{"value":260},{"value":0},{"value":4096},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13261940152},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5512263136},{"value":5512263200},{"value":13261943008},{"value":0},{"value":0},{"value":4096},{"value":4097},{"value":4352},{"value":0},{"value":5512261632}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13261940272},"sp":{"value":13261940128},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":36285,"name":"Java: http handler","threadState":{"x":[{"value":260},{"value":0},{"value":3840},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13264086456},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5277032928},{"value":5277032992},{"value":13264089312},{"value":0},{"value":0},{"value":3840},{"value":3841},{"value":4096},{"value":0},{"value":5277031424}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13264086576},"sp":{"value":13264086432},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":36291,"name":"Java: http handler","threadState":{"x":[{"value":260},{"value":0},{"value":3840},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13266232760},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5512121824},{"value":5512121888},{"value":13266235616},{"value":0},{"value":0},{"value":3840},{"value":3841},{"value":4096},{"value":0},{"value":5512120320}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13266232880},"sp":{"value":13266232736},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":36305,"name":"Java: http handler","threadState":{"x":[{"value":260},{"value":0},{"value":3840},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13272376760},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5512131552},{"value":5512131616},{"value":13272379616},{"value":0},{"value":0},{"value":3840},{"value":3841},{"value":4096},{"value":0},{"value":5512130048}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13272376880},"sp":{"value":13272376736},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":86406,"name":"Java: AWT-Shutdown","threadState":{"x":[{"value":260},{"value":0},{"value":1930434560},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6165571112},{"value":0},{"value":82688},{"value":355142255854338},{"value":355142255854338},{"value":82688},{"value":0},{"value":355142255854336},{"value":305},{"value":8541643384},{"value":0},{"value":5362785320},{"value":5362785384},{"value":6165573856},{"value":0},{"value":0},{"value":1930434560},{"value":1930434561},{"value":1930434816},{"value":105553120501648},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6165571232},"sp":{"value":6165571088},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8619776,"symbol":"PlatformEvent::park()","symbolLocation":120,"imageIndex":2},{"imageOffset":8479476,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1340,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4590132444,"imageIndex":26},{"imageOffset":4591570692,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":107702,"name":"Java: AWT-EventQueue-0","threadState":{"x":[{"value":260},{"value":0},{"value":1792},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6173369528},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":5276469216},{"value":5276469280},{"value":6173372640},{"value":0},{"value":0},{"value":1792},{"value":1793},{"value":2048},{"value":0},{"value":5276467712}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6173369648},"sp":{"value":6173369504},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4594205816,"imageIndex":26},{"imageOffset":4582051648,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":919226,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":28}],"threadState":{"x":[{"value":6163279872},{"value":118643},{"value":6162743296},{"value":0},{"value":409604},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6163279872},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629339368},"far":{"value":0}}},{"id":965708,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":28}],"threadState":{"x":[{"value":6143471616},{"value":42779},{"value":6142935040},{"value":0},{"value":409602},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6143471616},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629339368},"far":{"value":0}}},{"id":967157,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":28}],"threadState":{"x":[{"value":6142898176},{"value":97563},{"value":6142361600},{"value":0},{"value":409604},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6142898176},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629339368},"far":{"value":0}}},{"id":967615,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":28}],"threadState":{"x":[{"value":6166147072},{"value":120755},{"value":6165610496},{"value":0},{"value":409602},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6166147072},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629339368},"far":{"value":0}}},{"id":967749,"name":"Java: ForkJoinPool-1-worker-48","threadState":{"x":[{"value":260},{"value":0},{"value":5095936},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13256287896},{"value":0},{"value":25600},{"value":109951162803202},{"value":109951162803202},{"value":25600},{"value":0},{"value":109951162803200},{"value":305},{"value":8541643384},{"value":0},{"value":5068303328},{"value":5068303392},{"value":13256290528},{"value":0},{"value":0},{"value":5095936},{"value":5095937},{"value":5096192},{"value":0},{"value":5068301824}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13256288016},"sp":{"value":13256287872},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967750,"name":"Java: ForkJoinPool-1-worker-49","threadState":{"x":[{"value":260},{"value":0},{"value":40358144},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13268379288},{"value":0},{"value":185600},{"value":797145930323202},{"value":797145930323202},{"value":185600},{"value":0},{"value":797145930323200},{"value":305},{"value":8541643384},{"value":0},{"value":5520559072},{"value":5520559136},{"value":13268381920},{"value":0},{"value":0},{"value":40358144},{"value":40358145},{"value":40358400},{"value":0},{"value":5520557568}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13268379408},"sp":{"value":13268379264},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967754,"name":"Java: process reaper (pid 55791)","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":0},{"value":30350221560},{"value":32},{"value":2},{"value":30348934144},{"value":4294967276},{"value":8400908032,"symbolLocation":0,"symbol":"errno"},{"value":4343815988,"symbolLocation":0,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0"},{"value":26},{"value":34084883122160},{"value":5362836016},{"value":56},{"value":34084887178496},{"value":7},{"value":8541643648},{"value":0},{"value":55791},{"value":1},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":0},{"value":4582062592},{"value":6166407000},{"value":6166408560},{"value":34084883120424},{"value":0},{"value":5520269312}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4343816040},"cpsr":{"value":1610616832},"fp":{"value":6166406816},"sp":{"value":6166406688},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629123488},"far":{"value":0}},"frames":[{"imageOffset":34208,"symbol":"__wait4","symbolLocation":8,"imageIndex":27},{"imageOffset":24424,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0","symbolLocation":52,"imageIndex":5},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967755,"name":"Java: ForkJoinPool-1-worker-50","threadState":{"x":[{"value":260},{"value":0},{"value":286720},{"value":0},{"value":0},{"value":160},{"value":29},{"value":999724000},{"value":13278979736},{"value":0},{"value":218112},{"value":936783907083266},{"value":936783907083266},{"value":218112},{"value":0},{"value":936783907083264},{"value":305},{"value":8541643384},{"value":0},{"value":5076852704},{"value":5076852816},{"value":13278982368},{"value":999724000},{"value":29},{"value":286720},{"value":286721},{"value":286976},{"value":0},{"value":5076851200}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13278979856},"sp":{"value":13278979712},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621344,"symbol":"Parker::park(bool, long)","symbolLocation":492,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967756,"name":"Java: ForkJoinPool-1-worker-51","threadState":{"x":[{"value":260},{"value":0},{"value":34127872},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13467412120},{"value":0},{"value":187392},{"value":804842511719426},{"value":804842511719426},{"value":187392},{"value":0},{"value":804842511719424},{"value":305},{"value":8541643384},{"value":0},{"value":5077255648},{"value":5077255712},{"value":13467414752},{"value":0},{"value":0},{"value":34127872},{"value":34127873},{"value":34128128},{"value":0},{"value":5077254144}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13467412240},"sp":{"value":13467412096},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967757,"name":"Java: ForkJoinPool-1-worker-52","threadState":{"x":[{"value":260},{"value":0},{"value":39844352},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13473818264},{"value":0},{"value":203520},{"value":874111744285442},{"value":874111744285442},{"value":203520},{"value":0},{"value":874111744285440},{"value":305},{"value":8541643384},{"value":0},{"value":5084866016},{"value":5084866080},{"value":13473820896},{"value":0},{"value":0},{"value":39844352},{"value":39844353},{"value":39844608},{"value":0},{"value":5084864512}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13473818384},"sp":{"value":13473818240},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967758,"name":"Java: ForkJoinPool-1-worker-53","threadState":{"x":[{"value":260},{"value":0},{"value":44001536},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13475964568},{"value":0},{"value":240128},{"value":1031341907094018},{"value":1031341907094018},{"value":240128},{"value":0},{"value":1031341907094016},{"value":305},{"value":8541643384},{"value":0},{"value":5083807200},{"value":5083807264},{"value":13475967200},{"value":0},{"value":0},{"value":44001536},{"value":44001537},{"value":44001792},{"value":0},{"value":5083805696}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13475964688},"sp":{"value":13475964544},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967759,"name":"Java: ForkJoinPool-1-worker-54","threadState":{"x":[{"value":260},{"value":0},{"value":24168192},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13478110872},{"value":0},{"value":107008},{"value":459595860517378},{"value":459595860517378},{"value":107008},{"value":0},{"value":459595860517376},{"value":305},{"value":8541643384},{"value":0},{"value":5077914592},{"value":5077914656},{"value":13478113504},{"value":0},{"value":0},{"value":24168192},{"value":24168193},{"value":24168448},{"value":0},{"value":5077913088}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13478110992},"sp":{"value":13478110848},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967761,"name":"Java: ForkJoinPool-1-worker-55","threadState":{"x":[{"value":260},{"value":0},{"value":37044736},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":13480257176},{"value":0},{"value":171264},{"value":735573279153410},{"value":735573279153410},{"value":171264},{"value":0},{"value":735573279153408},{"value":305},{"value":8541643384},{"value":0},{"value":5270190048},{"value":5270190112},{"value":13480259808},{"value":0},{"value":0},{"value":37044736},{"value":37044737},{"value":37044992},{"value":0},{"value":5270188544}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13480257296},"sp":{"value":13480257152},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8621364,"symbol":"Parker::park(bool, long)","symbolLocation":512,"imageIndex":2},{"imageOffset":10227720,"symbol":"Unsafe_Park(JNIEnv_*, _jobject*, unsigned char, long)","symbolLocation":328,"imageIndex":2},{"imageOffset":4589657948,"imageIndex":26},{"imageOffset":4593762212,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967784,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":28}],"threadState":{"x":[{"value":6175092736},{"value":0},{"value":6174556160},{"value":0},{"value":278532},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6175092736},"esr":{"value":0,"description":" Address size fault"},"pc":{"value":6629339368},"far":{"value":0}}},{"id":967878,"name":"Java: Timer-0","threadState":{"x":[{"value":260},{"value":0},{"value":256},{"value":0},{"value":0},{"value":160},{"value":9},{"value":999999000},{"value":13829694872},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":4829195304},{"value":4829195368},{"value":13829697760},{"value":999999000},{"value":9},{"value":256},{"value":257},{"value":512},{"value":105553121295920},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13829694992},"sp":{"value":13829694848},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8620324,"symbol":"PlatformEvent::park_nanos(long)","symbolLocation":332,"imageIndex":2},{"imageOffset":8479444,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1308,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4590132444,"imageIndex":26},{"imageOffset":4590943184,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":967881,"name":"Java: dnd","threadState":{"x":[{"value":260},{"value":0},{"value":512},{"value":0},{"value":0},{"value":160},{"value":0},{"value":0},{"value":6184265176},{"value":0},{"value":0},{"value":2},{"value":2},{"value":0},{"value":0},{"value":0},{"value":305},{"value":8541643384},{"value":0},{"value":4821436712},{"value":4821436776},{"value":6184268000},{"value":0},{"value":0},{"value":512},{"value":513},{"value":768},{"value":105553120719280},{"value":2}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":6184265296},"sp":{"value":6184265152},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8619776,"symbol":"PlatformEvent::park()","symbolLocation":120,"imageIndex":2},{"imageOffset":8479476,"symbol":"ObjectMonitor::wait(long, bool, JavaThread*)","symbolLocation":1340,"imageIndex":2},{"imageOffset":9810500,"symbol":"ObjectSynchronizer::wait(Handle, long, JavaThread*)","symbolLocation":300,"imageIndex":2},{"imageOffset":5717292,"symbol":"JVM_MonitorWait","symbolLocation":440,"imageIndex":2},{"imageOffset":4590132444,"imageIndex":26},{"imageOffset":4589550924,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":968142,"name":"Java: C1 CompilerThread1","threadState":{"x":[{"value":516},{"value":0},{"value":11428864},{"value":0},{"value":0},{"value":160},{"value":5},{"value":0},{"value":13224667960},{"value":0},{"value":7169792},{"value":30794022166292226},{"value":30794022166292226},{"value":7169792},{"value":0},{"value":30794022166292224},{"value":305},{"value":8541643384},{"value":0},{"value":105553122889952},{"value":105553166929600},{"value":13224669408},{"value":0},{"value":5},{"value":11428864},{"value":11428864},{"value":11429376},{"value":6629394608,"symbolLocation":0,"symbol":"tlv_get_addr"},{"value":4375322624,"symbolLocation":32,"symbol":"OopOopIterateBoundedDispatch<VerifyCleanCardClosure>::_table"}],"flavor":"ARM_THREAD_STATE64","lr":{"value":6629361812},"cpsr":{"value":1610616832},"fp":{"value":13224668080},"sp":{"value":13224667936},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629107436},"far":{"value":0}},"frames":[{"imageOffset":18156,"symbol":"__psynch_cvwait","symbolLocation":8,"imageIndex":27},{"imageOffset":30868,"symbol":"_pthread_cond_wait","symbolLocation":1204,"imageIndex":28},{"imageOffset":8623280,"symbol":"PlatformMonitor::wait(unsigned long long)","symbolLocation":272,"imageIndex":2},{"imageOffset":8357712,"symbol":"Monitor::wait(unsigned long long)","symbolLocation":124,"imageIndex":2},{"imageOffset":2752872,"symbol":"CompileQueue::get(CompilerThread*)","symbolLocation":556,"imageIndex":2},{"imageOffset":2767152,"symbol":"CompileBroker::compiler_thread_loop()","symbolLocation":752,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]},{"id":968215,"name":"Java: process reaper (pid 55861)","threadState":{"x":[{"value":4},{"value":0},{"value":0},{"value":0},{"value":30284530704},{"value":32},{"value":2},{"value":30284660448},{"value":4294967276},{"value":8400908032,"symbolLocation":0,"symbol":"errno"},{"value":4343815988,"symbolLocation":0,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0"},{"value":26},{"value":34084883122160},{"value":5333101808},{"value":4294967295},{"value":34084887178496},{"value":7},{"value":8541643648},{"value":0},{"value":55861},{"value":1},{"value":4375589232,"symbolLocation":0,"symbol":"TemplateInterpreter::_active_table"},{"value":0},{"value":4582062592},{"value":6166669144},{"value":6166670704},{"value":34084883120424},{"value":0},{"value":5068112384}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4343816040},"cpsr":{"value":1610616832},"fp":{"value":6166668960},"sp":{"value":6166668832},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6629123488},"far":{"value":0}},"frames":[{"imageOffset":34208,"symbol":"__wait4","symbolLocation":8,"imageIndex":27},{"imageOffset":24424,"symbol":"Java_java_lang_ProcessHandleImpl_waitForProcessExit0","symbolLocation":52,"imageIndex":5},{"imageOffset":4582066516,"imageIndex":26},{"imageOffset":4582051744,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582053280,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582052128,"imageIndex":26},{"imageOffset":4582031700,"imageIndex":26},{"imageOffset":4922544,"symbol":"JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*)","symbolLocation":984,"imageIndex":2},{"imageOffset":4918248,"symbol":"JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*)","symbolLocation":328,"imageIndex":2},{"imageOffset":4918452,"symbol":"JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*)","symbolLocation":100,"imageIndex":2},{"imageOffset":5797520,"symbol":"thread_entry(JavaThread*, JavaThread*)","symbolLocation":156,"imageIndex":2},{"imageOffset":5003840,"symbol":"JavaThread::thread_main_inner()","symbolLocation":152,"imageIndex":2},{"imageOffset":10008076,"symbol":"Thread::call_run()","symbolLocation":200,"imageIndex":2},{"imageOffset":8588904,"symbol":"thread_native_entry(Thread*)","symbolLocation":280,"imageIndex":2},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":28},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":28}]}],
  "usedImages" : [
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4342267904,
    "CFBundleShortVersionString" : "15.3",
    "CFBundleIdentifier" : "io.xpipe.app",
    "size" : 81920,
    "uuid" : "8d2b8695-ec87-3d95-9387-4b1ab37ee7cb",
    "path" : "\/Applications\/XPipe.app\/Contents\/MacOS\/xpiped",
    "name" : "xpiped",
    "CFBundleVersion" : "15.3"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4343021568,
    "size" : 81920,
    "uuid" : "8f442ec8-6444-3e61-afd2-3fa07edd503e",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjli.dylib",
    "name" : "libjli.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4362190848,
    "size" : 12206080,
    "uuid" : "f806d0b0-3c61-3018-b6b6-e7754a96fa06",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/server\/libjvm.dylib",
    "name" : "libjvm.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4343185408,
    "size" : 16384,
    "uuid" : "ee867993-0a7d-345d-9d46-73ec3b15e7d7",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjimage.dylib",
    "name" : "libjimage.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4343431168,
    "size" : 98304,
    "uuid" : "0ecbeba6-b0a4-3efa-808e-f74d9d220aca",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libzip.dylib",
    "name" : "libzip.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4343791616,
    "size" : 81920,
    "uuid" : "908d9c2c-e617-3250-b950-e50547d03a04",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjava.dylib",
    "name" : "libjava.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5528092672,
    "size" : 17104896,
    "uuid" : "25448dda-832e-37c0-918c-6a52712fcf74",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjvmcicompiler.dylib",
    "name" : "libjvmcicompiler.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4344250368,
    "size" : 49152,
    "uuid" : "be999468-858f-3bb3-a96a-25fd73cf6ab5",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libnio.dylib",
    "name" : "libnio.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4343693312,
    "size" : 32768,
    "uuid" : "5ae991a4-ea4c-3ba8-bdcb-9c8ce35ba9e8",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libnet.dylib",
    "name" : "libnet.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4361551872,
    "size" : 49152,
    "uuid" : "99a1d584-42cf-3348-b1cf-64ea6190a338",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libverify.dylib",
    "name" : "libverify.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5093457920,
    "size" : 409600,
    "uuid" : "52290dd5-ba7e-3054-a877-0cd4ef655e50",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libawt.dylib",
    "name" : "libawt.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4820418560,
    "size" : 409600,
    "uuid" : "7e8f92cd-0695-30fb-a938-78c00b27ed7d",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libmlib_image.dylib",
    "name" : "libmlib_image.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5095440384,
    "size" : 753664,
    "uuid" : "6206de38-d471-3ff3-aa37-d078f25ee3f9",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libawt_lwawt.dylib",
    "name" : "libawt_lwawt.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 4361863168,
    "size" : 32768,
    "uuid" : "426bedde-c0f2-3214-bca0-f89b16bc10e6",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libosxapp.dylib",
    "name" : "libosxapp.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5097930752,
    "size" : 999424,
    "uuid" : "d2b8109a-eb61-3521-bbd7-cb20560e76c8",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libfontmanager.dylib",
    "name" : "libfontmanager.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5096685568,
    "size" : 507904,
    "uuid" : "a60a2ade-6d23-3ef7-869a-6cafb6844ff5",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libfreetype.dylib",
    "name" : "libfreetype.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 5053988864,
    "size" : 49152,
    "uuid" : "3d687e9b-e092-3632-bc1d-74b19d492de0",
    "path" : "\/usr\/lib\/libobjc-trampolines.dylib",
    "name" : "libobjc-trampolines.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 5598445568,
    "CFBundleShortVersionString" : "324.6",
    "CFBundleIdentifier" : "com.apple.AGXMetalG14X",
    "size" : 7520256,
    "uuid" : "da4fd60f-fe41-3f17-9e23-c9718a8013a3",
    "path" : "\/System\/Library\/Extensions\/AGXMetalG14X.bundle\/Contents\/MacOS\/AGXMetalG14X",
    "name" : "AGXMetalG14X",
    "CFBundleVersion" : "324.6"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5097455616,
    "size" : 32768,
    "uuid" : "be77fda4-dcaa-368e-82de-bba731d9e862",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libprism_es2.dylib",
    "name" : "libprism_es2.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 5267406848,
    "CFBundleShortVersionString" : "1.0",
    "CFBundleIdentifier" : "com.apple.AppleMetalOpenGLRenderer",
    "size" : 425984,
    "uuid" : "a969aeaf-d20c-3296-b195-742e2b280d5e",
    "path" : "\/System\/Library\/Extensions\/AppleMetalOpenGLRenderer.bundle\/Contents\/MacOS\/AppleMetalOpenGLRenderer",
    "name" : "AppleMetalOpenGLRenderer",
    "CFBundleVersion" : "1"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5327355904,
    "size" : 278528,
    "uuid" : "1c76b2bf-dbea-308b-97d6-905a360d35d8",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libglass.dylib",
    "name" : "libglass.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5097799680,
    "size" : 32768,
    "uuid" : "97f441d4-6d1e-32f0-a46a-b7a4d2317b93",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjavafx_font.dylib",
    "name" : "libjavafx_font.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5569609728,
    "size" : 114688,
    "uuid" : "7dd28c5c-989e-3bd1-ac2e-38b6e8e40a97",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libjnidispatch.jnilib",
    "name" : "libjnidispatch.jnilib"
  },
  {
    "source" : "P",
    "arch" : "arm64",
    "base" : 5332975616,
    "size" : 16384,
    "uuid" : "ce731169-f959-3cea-a399-f55237ba667e",
    "path" : "\/Applications\/XPipe.app\/Contents\/runtime\/Contents\/Home\/lib\/libxpipe_bridge.dylib",
    "name" : "libxpipe_bridge.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6629797888,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.CoreFoundation",
    "size" : 5197824,
    "uuid" : "190e6a36-fcaa-3ea3-94bb-7009c44653da",
    "path" : "\/System\/Library\/Frameworks\/CoreFoundation.framework\/Versions\/A\/CoreFoundation",
    "name" : "CoreFoundation",
    "CFBundleVersion" : "3302.1.400"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6648614912,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.Foundation",
    "size" : 14974976,
    "uuid" : "16d282d0-8b48-3e76-8036-fcb45dece518",
    "path" : "\/System\/Library\/Frameworks\/Foundation.framework\/Versions\/C\/Foundation",
    "name" : "Foundation",
    "CFBundleVersion" : "3302.1.400"
  },
  {
    "size" : 0,
    "source" : "A",
    "base" : 0,
    "uuid" : "00000000-0000-0000-0000-000000000000"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6629089280,
    "size" : 241656,
    "uuid" : "eee9d0d3-dffc-37cb-9ced-b27cd0286d8c",
    "path" : "\/usr\/lib\/system\/libsystem_kernel.dylib",
    "name" : "libsystem_kernel.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6629330944,
    "size" : 53248,
    "uuid" : "642faf7a-874e-37e6-8aba-2b0cc09a3025",
    "path" : "\/usr\/lib\/system\/libsystem_pthread.dylib",
    "name" : "libsystem_pthread.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6629384192,
    "size" : 184316,
    "uuid" : "c0c53058-94d2-3d9e-9e92-56ba8b43c327",
    "path" : "\/usr\/lib\/system\/libdyld.dylib",
    "name" : "libdyld.dylib"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6692417536,
    "CFBundleShortVersionString" : "6.9",
    "CFBundleIdentifier" : "com.apple.AppKit",
    "size" : 21221376,
    "uuid" : "b88a44c1-d617-33dc-90ed-b6ab417c428e",
    "path" : "\/System\/Library\/Frameworks\/AppKit.framework\/Versions\/C\/AppKit",
    "name" : "AppKit",
    "CFBundleVersion" : "2575.40.6"
  },
  {
    "source" : "P",
    "arch" : "arm64e",
    "base" : 6784946176,
    "CFBundleShortVersionString" : "1.8",
    "CFBundleIdentifier" : "com.apple.CoreVideo",
    "size" : 397312,
    "uuid" : "0fcfe924-013c-3974-9fdf-58f9a8d71845",
    "path" : "\/System\/Library\/Frameworks\/CoreVideo.framework\/Versions\/A\/CoreVideo",
    "name" : "CoreVideo",
    "CFBundleVersion" : "672.10"
  }
],
  "sharedCache" : {
  "base" : 6624854016,
  "size" : 4865835008,
  "uuid" : "d272b91e-f9f0-3854-b5b9-508b21c25dcc"
},
  "vmSummary" : "ReadOnly portion of Libraries: Total=1.6G resident=0K(0%) swapped_out_or_unallocated=1.6G(100%)\nWritable regions: Total=3.0G written=1446K(0%) resident=1446K(0%) swapped_out=0K(0%) unallocated=3.0G(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nAccelerate framework               128K        1 \nActivity Tracing                   256K        1 \nCG image                           288K        9 \nColorSync                          608K       30 \nCoreAnimation                      400K       20 \nCoreGraphics                        32K        2 \nCoreImage                           64K        4 \nCoreUI image data                 1776K       12 \nFoundation                          16K        1 \nKernel Alloc Once                   32K        1 \nMALLOC                             2.1G       74 \nMALLOC guard page                  288K       18 \nOpenGL GLSL                        256K        3 \nSTACK GUARD                       2944K       78 \nStack                            146.9M       78 \nStack Guard                       56.8M       52 \nVM_ALLOCATE                        5.3G      678 \nVM_ALLOCATE (reserved)           180.4M        8         reserved VM address space (unallocated)\n__AUTH                            5135K      658 \n__AUTH_CONST                      69.3M      900 \n__CTF                               824        1 \n__DATA                            44.7M      905 \n__DATA_CONST                      24.8M      931 \n__DATA_DIRTY                      2755K      334 \n__FONT_DATA                        2352        1 \n__GLSLBUILTINS                    5174K        1 \n__INFO_FILTER                         8        1 \n__LINKEDIT                       616.0M       25 \n__OBJC_RW                         2374K        1 \n__TEXT                             1.0G      951 \n__TPRO_CONST                       272K        2 \nmapped file                      441.0M       93 \nowned unmapped memory              496K        1 \npage table in kernel              1446K        1 \nshared memory                      912K       17 \n===========                     =======  ======= \nTOTAL                             10.0G     5893 \nTOTAL, minus reserved VM space     9.8G     5893 \n",
  "legacyInfo" : {
  "threadTriggered" : {
    "queue" : "com.apple.main-thread"
  }
},
  "logWritingSignature" : "c3481c6ea2dddc50d11cb8677136dd934698491c",
  "trialInfo" : {
  "rollouts" : [
    {
      "rolloutId" : "652eff3d1bce5442b8d753c9",
      "factorPackIds" : {

      },
      "deploymentId" : 240000009
    },
    {
      "rolloutId" : "6410af69ed1e1e7ab93ed169",
      "factorPackIds" : {

      },
      "deploymentId" : 240000011
    }
  ],
  "experiments" : [
    {
      "treatmentId" : "993c66e1-bf83-41fd-a09f-0d8d5906d223",
      "experimentId" : "664fc3cd79a61a0b8b557292",
      "deploymentId" : 500000013
    }
  ]
}
}

Model: Mac14,10, BootROM 11881.81.4, proc 12:8:4 processors, 16 GB, SMC 
Graphics: Apple M2 Pro, Apple M2 Pro, Built-In
Display: Color LCD, 3456 x 2234 Retina, Main, MirrorOff, Online
Memory Module: LPDDR5, Hynix
AirPort: spairport_wireless_card_type_wifi (0x14E4, 0x4388), wl0: Oct 31 2024 06:18:43 version 23.10.900.20.41.51.176 FWID 01-24228154
IO80211_driverkit-1345.10 "IO80211_driverkit-1345.10" Dec 14 2024 17:47:07
AirPort: 
Bluetooth: Version (null), 0 services, 0 devices, 0 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB31Bus
USB Device: USB31Bus
USB Device: USB31Bus
Thunderbolt Bus: MacBook Pro, Apple Inc.
Thunderbolt Bus: MacBook Pro, Apple Inc.
Thunderbolt Bus: MacBook Pro, Apple Inc.

From mstrauss at openjdk.org  Fri Mar  7 14:47:13 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 14:47:13 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
In-Reply-To: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
Message-ID: <leAHR1e7g1zeGn170uqeEf1bAKMBHXLystHMkm4BjAk=.67dda47d-ce9f-4175-8a8e-5038e93ade95@github.com>

On Thu, 6 Mar 2025 15:22:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

That's a good fix!

-------------

Marked as reviewed by mstrauss (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1730#pullrequestreview-2667456023

From angorya at openjdk.org  Fri Mar  7 15:30:50 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 15:30:50 GMT
Subject: RFR: 8351368: RichTextArea: exception pasting from Word [v2]
In-Reply-To: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
References: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
Message-ID: <Rf0eJgOxrCGXi45SFq7mBd67q0fJtYF5yYWKKc-q4QI=.2912e112-6b34-4c74-baf7-47fb0eb756ba@github.com>

> The original code used String attribute keys.
> 
> I'd like to backport this fix to jfx24u.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  ==

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1731/files
  - new: https://git.openjdk.org/jfx/pull/1731/files/b99db26d..00dee1d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1731&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1731&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1731.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1731/head:pull/1731

PR: https://git.openjdk.org/jfx/pull/1731

From angorya at openjdk.org  Fri Mar  7 15:33:00 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 15:33:00 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
Message-ID: <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>

On Fri, 7 Mar 2025 13:54:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8350048.enforce
>>  - review comments
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into 8350048.enforce
>>  - fixed node init test
>>  - all tests
>>  - initial test
>
> modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1187:
> 
>> 1185:      * This call is equivalent to {@code hide()}.
>> 1186:      * @throws IllegalStateException if this method is called on a thread
>> 1187:      * other than the JavaFX Application Thread.
> 
> Minor: add a blank line before `@throws`. I also think it's easier to read docs when multi-line text for a javadoc tag is indented, either by four spaces or lined up with the beginning of the first line of text (i.e. with the beginning of `IllegalStateException`).

good idea, even though it does not affect generated javadoc.
will do next time, to avoid re-setting the approvals ;-)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985268281

From mstrauss at openjdk.org  Fri Mar  7 15:40:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 15:40:58 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
Message-ID: <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>

On Fri, 7 Mar 2025 15:30:46 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> will do next time, to avoid re-setting the approvals ;-)

I'll re-approve if you decide to do the changes anyway.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985279553

From angorya at openjdk.org  Fri Mar  7 15:48:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 15:48:40 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v6]
In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
Message-ID: <fVKi4ij00Px6Y5PLHtTT7kKpFKyh1LOvsYsRgv5OJcE=.8fbefe74-d81c-4231-aabe-adf2f7f37459@github.com>

> - enforced fx application thread
> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
> - clarified `ComboBoxBase::show`
> - added a headful test `TestThreadingRestrictions`

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - indent
 - Merge remote-tracking branch 'origin/master' into 8350048.enforce
 - Merge remote-tracking branch 'origin/master' into 8350048.enforce
 - review comments
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8350048.enforce
 - fixed node init test
 - all tests
 - initial test

-------------

Changes: https://git.openjdk.org/jfx/pull/1717/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=05
  Stats: 480 lines in 13 files changed: 425 ins; 28 del; 27 mod
  Patch: https://git.openjdk.org/jfx/pull/1717.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717

PR: https://git.openjdk.org/jfx/pull/1717

From angorya at openjdk.org  Fri Mar  7 15:48:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 15:48:40 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
 <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
Message-ID: <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>

On Fri, 7 Mar 2025 15:38:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> good idea, even though it does not affect generated javadoc.
>> will do next time, to avoid re-setting the approvals ;-)
>
>> will do next time, to avoid re-setting the approvals ;-)
> 
> I'll re-approve if you decide to do the changes anyway.

it is not required, and the code is inconsistent (Stage:472) ... but ok.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985289103

From mstrauss at openjdk.org  Fri Mar  7 16:48:00 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 16:48:00 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
 <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
 <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>
Message-ID: <RBfIZnL17KOgn9VGOksvem3QRx2VKMQkfuKN7oDDG_w=.3444ce00-323e-4d4a-aef7-0abef42009d8@github.com>

On Fri, 7 Mar 2025 15:45:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> will do next time, to avoid re-setting the approvals ;-)
>> 
>> I'll re-approve if you decide to do the changes anyway.
>
> it is not required, and the code is inconsistent (Stage:472) ... but ok.

Can you do it for the other changed docs also?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985382006

From angorya at openjdk.org  Fri Mar  7 17:00:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 17:00:03 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <RBfIZnL17KOgn9VGOksvem3QRx2VKMQkfuKN7oDDG_w=.3444ce00-323e-4d4a-aef7-0abef42009d8@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
 <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
 <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>
 <RBfIZnL17KOgn9VGOksvem3QRx2VKMQkfuKN7oDDG_w=.3444ce00-323e-4d4a-aef7-0abef42009d8@github.com>
Message-ID: <RyAOveD0KMaCTDcxzh9BlIKO94Be0DLQNoyA5sJVk5I=.bd4cd35d-6d3e-4e55-a56c-c96cfef66667@github.com>

On Fri, 7 Mar 2025 16:45:18 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> it is not required, and the code is inconsistent (Stage:472) ... but ok.
>
> Can you do it for the other changed docs also?

The general policy is to avoid unrelated changes and expanding the scope.

A proper way to address that would be to create a JBS and do a wholesale bulk edit, not sure if it's worth it though.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985399107

From mstrauss at openjdk.org  Fri Mar  7 17:07:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 17:07:04 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <RyAOveD0KMaCTDcxzh9BlIKO94Be0DLQNoyA5sJVk5I=.bd4cd35d-6d3e-4e55-a56c-c96cfef66667@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
 <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
 <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>
 <RBfIZnL17KOgn9VGOksvem3QRx2VKMQkfuKN7oDDG_w=.3444ce00-323e-4d4a-aef7-0abef42009d8@github.com>
 <RyAOveD0KMaCTDcxzh9BlIKO94Be0DLQNoyA5sJVk5I=.bd4cd35d-6d3e-4e55-a56c-c96cfef66667@github.com>
Message-ID: <t4nXDuTiC1YEamBGxjikrji13u0GBvVqx5_xhumXBwc=.d076ddbe-fbf9-412b-b405-a3251c508913@github.com>

On Fri, 7 Mar 2025 16:57:05 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Can you do it for the other changed docs also?
>
> The general policy is to avoid unrelated changes and expanding the scope.
> 
> A proper way to address that would be to create a JBS and do a wholesale bulk edit, not sure if it's worth it though.

You've added the same javadoc tag in 20 different places. All I'm asking is that you do the change that you did in this particular place in all of the other places too.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985408805

From angorya at openjdk.org  Fri Mar  7 17:56:42 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 17:56:42 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v7]
In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
Message-ID: <aEFUePWuhApJhQLHET-YK-pCv-TlHivetG5mw0BjdVI=.441daa03-25fb-4982-869b-0936e14377b6@github.com>

> - enforced fx application thread
> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
> - clarified `ComboBoxBase::show`
> - added a headful test `TestThreadingRestrictions`

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - indent
 - indent

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1717/files
  - new: https://git.openjdk.org/jfx/pull/1717/files/2f2caa35..8663425c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1717&range=05-06

  Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jfx/pull/1717.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1717/head:pull/1717

PR: https://git.openjdk.org/jfx/pull/1717

From angorya at openjdk.org  Fri Mar  7 17:56:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 17:56:43 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v5]
In-Reply-To: <t4nXDuTiC1YEamBGxjikrji13u0GBvVqx5_xhumXBwc=.d076ddbe-fbf9-412b-b405-a3251c508913@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <QRtG7Sj9p9DhSyUSYMKz7ANKEA4RTLNp16f-N2M80Mw=.d63ffa46-e6e7-4ec8-8630-35460142ea7b@github.com>
 <rwI1xA5PSFQWIKtdAX5Gaw2HFqX3PaJeOyw-naFgJh8=.a8711034-b906-4397-9d39-6dea0b24b4cb@github.com>
 <HAu_j1Ra_XlMuI9jRIIYQ9s9WwWWE-OM_Q0bCgkacyg=.07d0318b-2e3f-4014-82f5-fad59a6bbe47@github.com>
 <nP_4S95hnE_sdbTD2edbGnixAhgidBYsJJZV8zeN76M=.ed5ea5e1-dd6e-4a51-b7b5-761854020a40@github.com>
 <hl5RsM-w1tTMY317YDFMr9Catl_7Li7eGjviYrm36jI=.19689c37-8af8-405c-9227-c0ce3e622263@github.com>
 <RBfIZnL17KOgn9VGOksvem3QRx2VKMQkfuKN7oDDG_w=.3444ce00-323e-4d4a-aef7-0abef42009d8@github.com>
 <RyAOveD0KMaCTDcxzh9BlIKO94Be0DLQNoyA5sJVk5I=.bd4cd35d-6d3e-4e55-a56c-c96cfef66667@github.com>
 <t4nXDuTiC1YEamBGxjikrji13u0GBvVqx5_xhumXBwc=.d076ddbe-fbf9-412b-b405-a3251c508913@github.com>
Message-ID: <TnrB7SIJxEYggw_qz1rwleOmcsSknWg-6ns-n7iA1U8=.2b7fbe2f-b4d2-4b88-aa70-d30a6a541763@github.com>

On Fri, 7 Mar 2025 17:04:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The general policy is to avoid unrelated changes and expanding the scope.
>> 
>> A proper way to address that would be to create a JBS and do a wholesale bulk edit, not sure if it's worth it though.
>
> You've added the same javadoc tag in 20 different places. All I'm asking is that you do the change that you did in this particular place in all of the other places too.

I misunderstood, sorry.  Done.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1717#discussion_r1985466380

From mstrauss at openjdk.org  Fri Mar  7 18:02:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 18:02:58 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v7]
In-Reply-To: <aEFUePWuhApJhQLHET-YK-pCv-TlHivetG5mw0BjdVI=.441daa03-25fb-4982-869b-0936e14377b6@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <aEFUePWuhApJhQLHET-YK-pCv-TlHivetG5mw0BjdVI=.441daa03-25fb-4982-869b-0936e14377b6@github.com>
Message-ID: <l6dtRpC3_ygHVTCrIU4Wv9iydq0-62Tfn1D-mCJTtCU=.942e1de7-e9c3-425d-9016-f4f336fae9de@github.com>

On Fri, 7 Mar 2025 17:56:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - enforced fx application thread
>> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
>> - clarified `ComboBoxBase::show`
>> - added a headful test `TestThreadingRestrictions`
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - indent
>  - indent

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1717#pullrequestreview-2667965598

From angorya at openjdk.org  Fri Mar  7 18:42:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 18:42:36 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>

> Changed the spec to require access only from the FX application thread.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - enforce
 - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
 - review comments
 - javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1728/files
  - new: https://git.openjdk.org/jfx/pull/1728/files/6a1a152e..0f39382c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=01-02

  Stats: 731 lines in 21 files changed: 573 ins; 115 del; 43 mod
  Patch: https://git.openjdk.org/jfx/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1728/head:pull/1728

PR: https://git.openjdk.org/jfx/pull/1728

From angorya at openjdk.org  Fri Mar  7 18:46:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 18:46:04 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
Message-ID: <-1qWUXzIto7FCcBtovoyHF31hL_jeI46JLKb6T0sPfQ=.2770ba7c-0550-4996-8bc8-fb388c7ea701@github.com>

On Fri, 7 Mar 2025 18:42:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding a listener or a binding to the global/static properties outside of the JavaFX application thread will likely cause concurrent access issues when the caller, still being executing in the background thread, receives an event in the context of the JavaFX application thread.
>> 
>> This change enforces accessing Platform::accessibilityActive only from the JavaFX application thread.
>> 
>> Q: should we also enforce the access rules for Platform::getPreferences() for the same reason?
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - enforce
>  - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
>  - review comments
>  - javadoc

@mstr2 : should we also enforce the access rules in `Platform::getPreferences()` ?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707167336

From mstrauss at openjdk.org  Fri Mar  7 21:07:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 21:07:58 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <-1qWUXzIto7FCcBtovoyHF31hL_jeI46JLKb6T0sPfQ=.2770ba7c-0550-4996-8bc8-fb388c7ea701@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <-1qWUXzIto7FCcBtovoyHF31hL_jeI46JLKb6T0sPfQ=.2770ba7c-0550-4996-8bc8-fb388c7ea701@github.com>
Message-ID: <v9oYIzHmJW3CR-UoBZ2ux3BLh1hrG-JQkjxD_2PrrYw=.5a8f2b70-d97c-4d2b-9aba-18bb63ea0af3@github.com>

On Fri, 7 Mar 2025 18:43:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> @mstr2 : should we also enforce the access rules in `Platform::getPreferences()` ?

In principle, yes. But just checking at the point of calling `Platform.getPreferences()` doesn't seem to be sufficient. An application could easily call `getPreferences()` on the FX thread, and then unsafely access the returned instance on another thread.

We should probably first come up with a systematic approach on how to solve these kinds of problems, and not do ad-hoc solutions here and there.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707457414

From angorya at openjdk.org  Fri Mar  7 21:16:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 21:16:59 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
Message-ID: <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>

On Fri, 7 Mar 2025 18:42:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Adding a listener or a binding to the global/static properties outside of the JavaFX application thread will likely cause concurrent access issues when the caller, still being executing in the background thread, receives an event in the context of the JavaFX application thread.
>> 
>> This change enforces accessing Platform::accessibilityActive only from the JavaFX application thread.
>> 
>> Q: should we also enforce the access rules for Platform::getPreferences() for the same reason?
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - enforce
>  - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
>  - review comments
>  - javadoc

This **is** the time we systematically approach the subject, see https://bugs.openjdk.org/browse/JDK-8348987

The case we are trying to deal with explicitly is initialization of Nodes in the background threads which is permitted.  We are not addressing the misuse of APIs by the applications, only providing a mechanism to fail early in the narrow case when controls/skins/nodes try access the Platform globals.

I believe `::getPReferences()` is the only API in the `Platform` left without the explicit check, thus the question.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707468115

From mstrauss at openjdk.org  Fri Mar  7 21:36:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 21:36:56 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
Message-ID: <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>

On Fri, 7 Mar 2025 21:11:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> We are not addressing the misuse of APIs by the applications, only providing a mechanism to fail early in the narrow case when controls/skins/nodes try access the Platform globals.

Then I diagree with the problem statement. Calling out to `checkFxUserThread` in the property getter is a very superficial fix that's not materially better than simply documenting that we assume the property only be used on the FX thread.

On a related note, I would like to see us move to a more structured form of documentation, for example with custom javadoc tags. This makes it easier to see information at a glance in the generated documentation.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707502997

From angorya at openjdk.org  Fri Mar  7 21:42:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 21:42:01 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
 <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>
Message-ID: <L6juScyp3PE0P44gZdj21G8PUw7qhPWfJxwGfTKt13E=.5c8aafcc-b6dc-4069-bdb4-f4c94c0ad82f@github.com>

On Fri, 7 Mar 2025 21:34:14 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> move to a more structured form of documentation, for example with custom javadoc tags.

what custom tags?  could you elaborate?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707510227

From nlisker at openjdk.org  Fri Mar  7 21:59:59 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 7 Mar 2025 21:59:59 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
In-Reply-To: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
Message-ID: <w9I9dv3TUFDpvSZlEak_y6RFJEgjNRDB-dJNsjMdQJE=.17fd74c6-2385-4a06-8ed0-d3d4d18c0344@github.com>

On Thu, 6 Mar 2025 15:22:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed

modules/javafx.base/src/main/java/com/sun/javafx/binding/LazyObjectBinding.java line 62:

> 60:         updateSubscriptionBeforeAdd();
> 61: 
> 62:         super.addListener(listener);

I noticed that reverting this change causes all the `GivenAQuadMappedObservable` to fails, but reverting the add `ChangeListener` method change causes only change listener tests to fail. Is this correct? Shouldn't there be a tests that fails just the invalidation listener code?

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

> 376:          * can first become observed (allowing caching) and are then queried (likely
> 377:          * getting the value from the cache). Doing this the other way around would
> 378:          * result in the value (or chain of values) being computed twice.

If I understand correctly, it will be computed twice because the observable would not be able to cache the value yet. It will compute it once without caching with `getValue()`, and then again with `addListener(...)`. If this is correct, I suggest writing a short continuation: 
"Doing this the other way around would result in the value (or chain of values) being computed twice because ___."

modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 61:

> 59:     private final InvalidationListener invalidationListener = obs -> invalidations++;
> 60: 
> 61:     private StringProperty property = new SimpleStringProperty("Initial");

`final`?

modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 65:

> 63:     @Nested
> 64:     class GivenAQuadMappedObservable {
> 65:         AtomicInteger calls1 = new AtomicInteger(0);

Empty line after the class declaration.

modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 80:

> 78:             assertEquals(0, calls2.get());
> 79:             assertEquals(0, calls3.get());
> 80:             assertEquals(0, calls4.get());

Since these assertions are a repeating pattern, do you want to extract it to a reusable method?


private void assertValue(int val) {
    assertEquals(val, calls1.get());
    assertEquals(val, calls2.get());
    assertEquals(val, calls3.get());
    assertEquals(val, calls4.get());
}

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985752123
PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985677539
PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985679166
PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985680283
PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985667361

From mstrauss at openjdk.org  Fri Mar  7 22:01:56 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 7 Mar 2025 22:01:56 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <L6juScyp3PE0P44gZdj21G8PUw7qhPWfJxwGfTKt13E=.5c8aafcc-b6dc-4069-bdb4-f4c94c0ad82f@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
 <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>
 <L6juScyp3PE0P44gZdj21G8PUw7qhPWfJxwGfTKt13E=.5c8aafcc-b6dc-4069-bdb4-f4c94c0ad82f@github.com>
Message-ID: <hjfXscOdZ3h88g_n5MpNZqtb6rcoBNqW3GPHkdUQAzc=.42481c71-fa1b-4342-a948-28f9216997d3@github.com>

On Fri, 7 Mar 2025 21:39:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> what custom tags? could you elaborate?

Maybe a custom tag like `@threadAccess JavaFX application thread`. This would then show up in the generated property list instead of the summary text. We already do this for `@interpolationType`.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707538337

From jhendrikx at openjdk.org  Fri Mar  7 22:45:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Mar 2025 22:45:00 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
In-Reply-To: <w9I9dv3TUFDpvSZlEak_y6RFJEgjNRDB-dJNsjMdQJE=.17fd74c6-2385-4a06-8ed0-d3d4d18c0344@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
 <w9I9dv3TUFDpvSZlEak_y6RFJEgjNRDB-dJNsjMdQJE=.17fd74c6-2385-4a06-8ed0-d3d4d18c0344@github.com>
Message-ID: <kjzfZMh3r0SmH75yM0iHZrKgYeSo8CiTo-bJExbGKTM=.513c9d15-f430-4908-8fe4-873da0a02ac4@github.com>

On Fri, 7 Mar 2025 21:46:03 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/LazyObjectBinding.java line 62:
> 
>> 60:         updateSubscriptionBeforeAdd();
>> 61: 
>> 62:         super.addListener(listener);
> 
> I noticed that reverting this change causes all the `GivenAQuadMappedObservable` to fails, but reverting the add `ChangeListener` method change causes only change listener tests to fail. Is this correct? Shouldn't there be a tests that fails just the invalidation listener code?

The lazy Bindings all use invalidation listeners internally, so there will always be some invalidation listeners in these cases.  There is the listener that the user adds (invalidation, change or the subscription variants that use one of these), and there are the 4 internal invalidation listeners needed to support the 4 mappings which are added and removed when observed only.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985807316

From angorya at openjdk.org  Fri Mar  7 22:57:56 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 7 Mar 2025 22:57:56 GMT
Subject: RFR: 8351067: Enforce Platform::accessibilityActive threading use
 [v3]
In-Reply-To: <hjfXscOdZ3h88g_n5MpNZqtb6rcoBNqW3GPHkdUQAzc=.42481c71-fa1b-4342-a948-28f9216997d3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
 <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>
 <L6juScyp3PE0P44gZdj21G8PUw7qhPWfJxwGfTKt13E=.5c8aafcc-b6dc-4069-bdb4-f4c94c0ad82f@github.com>
 <hjfXscOdZ3h88g_n5MpNZqtb6rcoBNqW3GPHkdUQAzc=.42481c71-fa1b-4342-a948-28f9216997d3@github.com>
Message-ID: <k0NVAcBl-I7LJVpiO5rovGiERvkk2KBOti9CcE_HTsw=.936b60b6-b957-42ef-9e7e-81918c3fff52@github.com>

On Fri, 7 Mar 2025 21:59:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> @threadAccess JavaFX application thread

Out of scope for this PR, but it might be a good idea.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2707661783

From jhendrikx at openjdk.org  Fri Mar  7 22:57:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Fri, 7 Mar 2025 22:57:59 GMT
Subject: RFR: 8351276: Prevent redundant computeValue calls when a chain of
 mappings becomes observed
In-Reply-To: <w9I9dv3TUFDpvSZlEak_y6RFJEgjNRDB-dJNsjMdQJE=.17fd74c6-2385-4a06-8ed0-d3d4d18c0344@github.com>
References: <IyHADMCaatpnRYZ2g7a6OHCDsuw7JZULs-dbWKmssv8=.25763986-bb17-4600-b505-0fdd9b601f26@github.com>
 <w9I9dv3TUFDpvSZlEak_y6RFJEgjNRDB-dJNsjMdQJE=.17fd74c6-2385-4a06-8ed0-d3d4d18c0344@github.com>
Message-ID: <9ypcAcNijRizy7YIHd7lQZs0W7ArcB94n21INBQsyIU=.c92e6e60-7373-407d-92c7-cb9f9c7d1c0d@github.com>

On Fri, 7 Mar 2025 20:38:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> 8351276: Prevent redundant computeValue calls when a chain of mappings becomes observed
>
> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java line 378:
> 
>> 376:          * can first become observed (allowing caching) and are then queried (likely
>> 377:          * getting the value from the cache). Doing this the other way around would
>> 378:          * result in the value (or chain of values) being computed twice.
> 
> If I understand correctly, it will be computed twice because the observable would not be able to cache the value yet. It will compute it once without caching with `getValue()`, and then again with `addListener(...)`. If this is correct, I suggest writing a short continuation: 
> "Doing this the other way around would result in the value (or chain of values) being computed twice because ___."

If you add the listener first, then `ExpressionHelper` will do a `getValue` causing the 4 mappings to be computed but without being able to cache them as the bindings are not yet aware there is a listener present now (and so will remain "invalid").  The observable belonging to the last mapping will then have its `observeSources` called.  This adds another listener (on the 3rd mapping, via the invalidation listener endpoint, which had the same ordering issue).  Again, `ExpressionHelper` will try get the value, and 3 mappings will be recomputed (the 4th mapping is not computed again as its `observeSources` was called already).  This continues when the listener is added on the 2nd mapping (and 2 mappings are recomputed), and on the first mapping (computing that one, one final time).

So I guess the continuation could be something like:

"... because the process of adding a listener triggers the computation of the observable's value which, when called before #observeSource  was called, won't be cached yet."

> modules/javafx.base/src/test/java/test/javafx/beans/value/ObservableValueFluentBindingsTest.java line 80:
> 
>> 78:             assertEquals(0, calls2.get());
>> 79:             assertEquals(0, calls3.get());
>> 80:             assertEquals(0, calls4.get());
> 
> Since these assertions are a repeating pattern, do you want to extract it to a reusable method?
> 
> 
> private void assertValue(int val) {
>     assertEquals(val, calls1.get());
>     assertEquals(val, calls2.get());
>     assertEquals(val, calls3.get());
>     assertEquals(val, calls4.get());
> }

Not really, I'd prefer to be explicit in tests.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985815678
PR Review Comment: https://git.openjdk.org/jfx/pull/1730#discussion_r1985816609

From nlisker at openjdk.org  Sat Mar  8 04:40:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sat, 8 Mar 2025 04:40:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
Message-ID: <2t7Ry2uAAMB4Oy_VNHN6NCVd59k3dLOVT2Pye-8n4eQ=.7496f449-d20a-4338-9f18-c6d94728dd7d@github.com>

On Thu, 6 Mar 2025 16:21:33 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
>> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener (excluding unused slots)|61 + 4 per listener (excluding unused slots)|
>> 
>> # About nested changes
>> 
>> Nested changes are simply changes...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix non-convergence logic one more time...

I have done some more tests with nested value changes converging and diverging. Overall I've tested over 20 scenarios of nested changes (including addition/removal of listers). Looks good. Great job!

I'll finish going over the implementation with the new changes.

> > > Note that the non-convergence detection logic is pretty smart, as the test case where multiple listeners are trying to agree upon a value that is divisible by 3, 5, 7 and 11 still works fine
> > 
> > 
> > And what about non-integer values, like custom objects or strings?
> 
> I fail to see how this would make a difference. The test case demonstrates...

I missed that you were talking about a specific test.

---

Do you mind adding somewhere in the top comment a link to https://github.com/openjdk/jfx/pull/837 for bookkeeping purpose?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2708012349

From mstrauss at openjdk.org  Sat Mar  8 08:21:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 8 Mar 2025 08:21:03 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v16]
In-Reply-To: <90IwTCTcUFrYPloNeeONG7AcomZThZ0Bz54N5YPVLnM=.33cb0b1e-8143-4ff2-80d9-82e1cd82b4db@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ZIaXEMTbtzvZ8arXaFwUH5bp0-ubCsEvmx_NawNDuN4=.114e6bd5-1df2-4c49-805c-12a13512fb68@github.com>
 <koMHkh-j6oEyEkfkggbpNlwub3pGwXy7FIwZCA7KKRc=.0f9ae1b7-4e0c-4722-913b-e6fbffb6a379@github.com>
 <90IwTCTcUFrYPloNeeONG7AcomZThZ0Bz54N5YPVLnM=.33cb0b1e-8143-4ff2-80d9-82e1cd82b4db@github.com>
Message-ID: <Dw6EWbUByl22wyagOuzHhv_Ueagfn48KHYLlRJS2BLs=.d9f3af81-8c44-484e-bb94-60b81c0bdcf4@github.com>

On Wed, 5 Feb 2025 20:33:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismCaretInfo.java line 48:
>> 
>>> 46:     @Override
>>> 47:     public Rectangle2D getSegmentAt(int index) {
>>> 48:         return parts[index];
>> 
>> do we need a bound check here?
>
> no special handling is needed here I think: an exception will be thrown

While true, I think we should throw `IndexOutOfBoundsException` rather than `ArrayIndexOutOfBoundsException` (use `Objects.checkIndex()` for that). This should also be specified with a `@throws` javadoc tag in `CaretInfo`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1986027817

From mstrauss at openjdk.org  Sat Mar  8 08:26:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 8 Mar 2025 08:26:06 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
Message-ID: <NQo56qs2eY6WDuqLWkDhpcA3NAWtE3OMsawBDBFEmkM=.05f01c23-1250-4e26-814d-7c8cd218eb8b@github.com>

On Wed, 5 Mar 2025 21:18:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - Merge branch 'master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge branch 'master' into ag.text.layout.api
>  - segments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismCaretInfo.java line 54:

> 52:     public String toString() {
> 53:         StringBuilder sb = new StringBuilder();
> 54:         sb.append("PrismCaretInfo{parts=[");

I think you shouldn't leak implementation details via the `toString()` method (the name of the implementing class, as well as `parts=`, which is not a term that appears in the API). Maybe just drop `PrismCaretInfo{parts=` entirely.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1986028427

From mstrauss at openjdk.org  Sat Mar  8 08:32:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 8 Mar 2025 08:32:03 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
Message-ID: <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>

On Wed, 5 Mar 2025 21:18:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - Merge branch 'master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge branch 'master' into ag.text.layout.api
>  - segments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 256:

> 254:      * @return the caret geometry
> 255:      */
> 256:     public float[] getCaretGeometry(int offset, boolean leading);

Does this method throw any exceptions? If so, please specify.

modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 271:

> 269:      * @param client the callback to invoke for each rectangular shape
> 270:      */
> 271:     public void getRange(int start, int end, int type, GeometryCallback client);

Does this method throw any exceptions?

modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 41:

> 39:  * @since 25
> 40:  */
> 41: public abstract class LayoutInfo {

Any exceptions thrown by methods of this class?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1986028504
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1986028592
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1986029390

From jhendrikx at openjdk.org  Sat Mar  8 10:44:04 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 8 Mar 2025 10:44:04 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <2t7Ry2uAAMB4Oy_VNHN6NCVd59k3dLOVT2Pye-8n4eQ=.7496f449-d20a-4338-9f18-c6d94728dd7d@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <2t7Ry2uAAMB4Oy_VNHN6NCVd59k3dLOVT2Pye-8n4eQ=.7496f449-d20a-4338-9f18-c6d94728dd7d@github.com>
Message-ID: <ZZqoaW3shA0B4owvFGTWIwNxAJIOnz9Wq8tXzVd4xCo=.217ce204-81e8-49e9-806a-d5c276707fdb@github.com>

On Sat, 8 Mar 2025 04:37:04 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> I have done some more tests with nested value changes converging and diverging. Overall I've tested over 20 scenarios of nested changes (including addition/removal of listers). Looks good. Great job!

Thanks, and thank you for putting in so much testing effort for this.  Anything I should add as test-cases?

> I missed that you were talking about a specific test.

Ah, okay, that explains my confusion as well.

> Do you mind adding somewhere in the top comment a link to #837 for bookkeeping purpose?

I added a link. I almost forgot about that implementation which took a different route.  I seem to remember there being issues when emissions weren't started nested, but queued up instead.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2708196447

From kcr at openjdk.org  Sat Mar  8 14:45:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 8 Mar 2025 14:45:58 GMT
Subject: RFR: 8351368: RichTextArea: exception pasting from Word [v2]
In-Reply-To: <Rf0eJgOxrCGXi45SFq7mBd67q0fJtYF5yYWKKc-q4QI=.2912e112-6b34-4c74-baf7-47fb0eb756ba@github.com>
References: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
 <Rf0eJgOxrCGXi45SFq7mBd67q0fJtYF5yYWKKc-q4QI=.2912e112-6b34-4c74-baf7-47fb0eb756ba@github.com>
Message-ID: <pHV-_SKv8LTqKHA3P0_U_Xf5QxwP1Vp5VvdmVSLo-nM=.410cd810-db7e-4d69-a32d-65971ad98c8f@github.com>

On Fri, 7 Mar 2025 15:30:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The original code used String attribute keys.
>> 
>> I'd like to backport this fix to jfx24u.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ==

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1731#pullrequestreview-2669197133

From nlisker at openjdk.org  Sun Mar  9 22:04:03 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Sun, 9 Mar 2025 22:04:03 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <ZZqoaW3shA0B4owvFGTWIwNxAJIOnz9Wq8tXzVd4xCo=.217ce204-81e8-49e9-806a-d5c276707fdb@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <2t7Ry2uAAMB4Oy_VNHN6NCVd59k3dLOVT2Pye-8n4eQ=.7496f449-d20a-4338-9f18-c6d94728dd7d@github.com>
 <ZZqoaW3shA0B4owvFGTWIwNxAJIOnz9Wq8tXzVd4xCo=.217ce204-81e8-49e9-806a-d5c276707fdb@github.com>
Message-ID: <TfgYUZYcfQ4NdzDH093QmHdIPu9Z56Xe_H7JRokig3k=.84898572-b1ab-418e-917d-67c6ff315418@github.com>

On Sat, 8 Mar 2025 10:41:29 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Anything I should add as test-cases?

When I do the review of the tests I'll compare with my scenarios and see if there's anything worth adding.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2709090436

From nlisker at openjdk.org  Mon Mar 10 02:37:08 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Mon, 10 Mar 2025 02:37:08 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
Message-ID: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>

On Thu, 6 Mar 2025 16:21:33 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix non-convergence logic one more time...

First part of the review.

There are several class (and their methods) that are `public`, but are only used in their package and can just have package-access:
`OldValueCachingListenerList`
`ListenerManagerBase`
`ListenerListBase`
`ListenerList`
`ArrayManager`

If they are `public` because of tests, please add a comment like "public for testing purpose".

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 45:

> 43:  * a {@link ListenerList}. It is recommended to never inspect this field directly
> 44:  * but always use this manager to interact with it.
> 45:  *

I suggest adding a line that says that this class is used by bindings.

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 49:

> 47:  * @param <I> the type of the instance providing listener data
> 48:  */
> 49: public abstract class ListenerManager<T, I extends ObservableValue<? extends T>> extends ListenerManagerBase<T, I> {

Same comments from `OldValueCachingListenerManager`.

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerList.java line 41:

> 39:  */
> 40: public class OldValueCachingListenerList<T> extends ListenerList<T> {
> 41:     private T latestValue;

Empty line after class declaration.

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 43:

> 41:  * only a single invalidation listener, the field will contain only that
> 42:  * listener (change listeners are wrapped to track old value). When there is more
> 43:  * than one listener, the field will hold a {@link OldValueCachingListenerList}. It

Suggestion:

 * than one listener, the field will hold an {@link OldValueCachingListenerList}. It

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 53:

> 51:  * within listener list. If possible use {@link ListenerManager}, as it has less
> 52:  * storage requirements and is faster.
> 53:  *

I suggest adding a line that says that this class is used by properties.

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 64:

> 62:      * @param instance the instance to which the listeners belong, cannot be {@code null}
> 63:      * @param listener a listener to add, cannot be {@code null}
> 64:      * @throws NullPointerException when listener is {@code null}

And when `instance` is too, no? One will throw implicitly and the other explicitly. Does it matter for the docs?

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 90:

> 88:         else {
> 89:             setData(instance, new OldValueCachingListenerList<>(data, listener));
> 90:         }

This can now be a pattern matching `switch`:

        switch (data) {
            case null -> setData(instance, listener);
            case OldValueCachingListenerList<?> list -> list.add(listener);
            case ChangeListenerWrapper<?> wrapper -> {
                var list = new OldValueCachingListenerList<>(wrapper.listener, listener);

                list.putLatestValue(wrapper.latestValue);

                setData(instance, list);
            }
            default -> setData(instance, new OldValueCachingListenerList<>(data, listener));
        }

Note that in the case of `ChangeListenerWrapper` (in your code too) there's no compile-time need to cast to a `T` type because `OldValueCachingListenerList` takes `Object`s and so does `setData`. Is this a required runtime check?

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 100:

> 98:      * @throws NullPointerException when listener is {@code null}
> 99:      */
> 100:     public void addListener(I instance, ChangeListener<? super T> listener) {

Same remarks from the invalidation listener method, but does `instance` not need a `null` check or does `getData` do that? It's not so clear.

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 143:

> 141:      * @throws NullPointerException when listener is {@code null}
> 142:      */
> 143:     public void removeListener(I instance, Object listener) {

Same comments.

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 168:

> 166:      *   can be {@code null} which means there are no listeners to notify
> 167:      */
> 168:     public void fireValueChanged(I instance, Object listenerData) {

Same comments. `null` check on `instance`?

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 206:

> 204:     }
> 205: 
> 206:     static class ChangeListenerWrapper<T> implements ChangeListener<T> {

Can be `private`?

modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 207:

> 205: 
> 206:     static class ChangeListenerWrapper<T> implements ChangeListener<T> {
> 207:         private final ChangeListener<T> listener;

Empty line.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2669538281
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986508160
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986507024
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986433772
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986436187
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986508555
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986437446
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986435854
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986437897
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986440318
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986443411
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986495228
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986444995

From jhendrikx at openjdk.org  Mon Mar 10 07:40:05 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 07:40:05 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <ROxUcok2zDBAZX5kLpuaMEm_gwrc39vZ34oDeZHeDCg=.381965e6-60c1-4a77-971a-b0d5f6c66286@github.com>

On Mon, 10 Mar 2025 02:34:02 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> First part of the review.
> 
> There are several class (and their methods) that are `public`, but are only used in their package and can just have package-access: `OldValueCachingListenerList` `ListenerManagerBase` `ListenerListBase` `ListenerList` `ArrayManager`
> 
> If they are `public` because of tests, please add a comment like "public for testing purpose"

I understand that making a **method** public that shouldn't be should be documented as such, but what's against having public classes in non-exported packages even if just for testing purposes?  This is done widely through out FX already.  

Also these classes are well documented, and there's no reason they could not be used outside their package, even if they currently are not.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2709675601

From jhendrikx at openjdk.org  Mon Mar 10 07:55:20 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 07:55:20 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <szy6uS85nIpkkNv19LdI0y4dCkt0AjR1ApAXJSgbc0w=.1544eef7-57f3-4a66-bd6d-7750cb51cce7@github.com>

On Sun, 9 Mar 2025 22:27:00 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-convergence logic one more time...
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 90:
> 
>> 88:         else {
>> 89:             setData(instance, new OldValueCachingListenerList<>(data, listener));
>> 90:         }
> 
> This can now be a pattern matching `switch`:
> 
>         switch (data) {
>             case null -> setData(instance, listener);
>             case OldValueCachingListenerList<?> list -> list.add(listener);
>             case ChangeListenerWrapper<?> wrapper -> {
>                 var list = new OldValueCachingListenerList<>(wrapper.listener, listener);
> 
>                 list.putLatestValue(wrapper.latestValue);
> 
>                 setData(instance, list);
>             }
>             default -> setData(instance, new OldValueCachingListenerList<>(data, listener));
>         }
> 
> Note that in the case of `ChangeListenerWrapper` (in your code too) there's no compile-time need to cast to a `T` type because `OldValueCachingListenerList` takes `Object`s and so does `setData`. Is this a required runtime check?

This looks like a good change. The runtime check is not required, I just always specify generics when needed, and in this case I thought I had no choice but to use `<T>`.  I've adjusted it slightly:

        switch (getData(instance)) {
            case null -> setData(instance, listener);
            case OldValueCachingListenerList<?> list -> list.add(listener);
            case ChangeListenerWrapper<?> wrapper -> {
                OldValueCachingListenerList<Object> list = new OldValueCachingListenerList<>(wrapper.listener, listener);

                list.putLatestValue(wrapper.latestValue);
                setData(instance, list);
            }
            case Object data -> setData(instance, new OldValueCachingListenerList<>(data, listener));
        }
        
Primarily, I've not declared a `data` local anymore (so you can't use it accidentally in the cases).  For this I removed the default case and instead did `case Object data ->`.  It's still exhaustive :)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986766329

From jhendrikx at openjdk.org  Mon Mar 10 08:39:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 08:39:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <WiUipo_k1_PkF6p638uz1yQIpSrBtl4P8mm8sN3Uih4=.bff19a17-f63b-488b-85fa-48ac1739023d@github.com>

On Sun, 9 Mar 2025 22:36:42 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-convergence logic one more time...
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 64:
> 
>> 62:      * @param instance the instance to which the listeners belong, cannot be {@code null}
>> 63:      * @param listener a listener to add, cannot be {@code null}
>> 64:      * @throws NullPointerException when listener is {@code null}
> 
> And when `instance` is too, no? One will throw implicitly and the other explicitly. Does it matter for the docs?

I've updated all of these to `throws NullPointerException when any argument is {@code null}`

How it is done exactly is irrelevant for the docs :)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986823574

From jhendrikx at openjdk.org  Mon Mar 10 08:45:09 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 08:45:09 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <XGLu7DaV7i_X_N3UIJL-7BomTubF3BEoC9J5AQ41Zn0=.edb57bfc-c74c-41c8-be55-3c95b61c52eb@github.com>

On Mon, 10 Mar 2025 02:07:04 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-convergence logic one more time...
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 53:
> 
>> 51:  * within listener list. If possible use {@link ListenerManager}, as it has less
>> 52:  * storage requirements and is faster.
>> 53:  *
> 
> I suggest adding a line that says that this class is used by properties.

That doesn't seem like something you should be adding to the docs I think?

> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 100:
> 
>> 98:      * @throws NullPointerException when listener is {@code null}
>> 99:      */
>> 100:     public void addListener(I instance, ChangeListener<? super T> listener) {
> 
> Same remarks from the invalidation listener method, but does `instance` not need a `null` check or does `getData` do that? It's not so clear.

This is basically handed off to individual implementations (`getData` is abstract), for example in `FloatBinding`:

    private static final ListenerManager<Number, FloatBinding> LISTENER_MANAGER = new ListenerManager<>() {
        @Override
        protected Object getData(FloatBinding instance) {
            return instance.listenerData;
        }

        @Override
        protected void setData(FloatBinding instance, Object data) {
            instance.listenerData = data;
        }
    };
    
I've updated the docs for the abstract methods to include that these should throw NPE when `instance` is `null`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986834518
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986828001

From jhendrikx at openjdk.org  Mon Mar 10 08:48:53 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 08:48:53 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener...

John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:

 - Small fixes from review comments
 - Use switch expression where reasonable
 - Update docs regarding NullPointerExceptions

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/5863932f..3c385444

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=11
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=10-11

  Stats: 84 lines in 4 files changed: 13 ins; 32 del; 39 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From mstrauss at openjdk.org  Mon Mar 10 09:32:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 09:32:11 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
Message-ID: <GZS2937V-Mf2--0Vhym2Xz-ihQdzMYo0euzruVL_S_A=.8bb52270-3201-4062-b177-854316d07fbe@github.com>

On Mon, 10 Mar 2025 08:48:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small fixes from review comments
>  - Use switch expression where reasonable
>  - Update docs regarding NullPointerExceptions

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 174:

> 172:                  */
> 173: 
> 174:                 throw new StackOverflowError("non-converging value detected in value modifying listeners on " + observableValue + "; original value was: " + oldValue);

We shouldn't throw errors, even if that's what the old implementation would implicitly do (not that it matters, no sane application would ever try to catch a `StackOverflowError` as part of its normal control flow). I think a `RuntimeException` is in order.

Also maybe make the message a bit clearer:
`<observableValue> was changed during the invocation of multiple listeners, but the new values diverge [original value: <oldValue>]`

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986911609

From mstrauss at openjdk.org  Mon Mar 10 09:35:10 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 09:35:10 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <YdVuwyAjxUwKvCrK1C2j75pmaMOwYtjyXbMk8ONeVa8=.f65264a7-f9ef-4e63-a86e-74331283b905@github.com>

On Mon, 10 Mar 2025 02:06:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-convergence logic one more time...
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManager.java line 45:
> 
>> 43:  * a {@link ListenerList}. It is recommended to never inspect this field directly
>> 44:  * but always use this manager to interact with it.
>> 45:  *
> 
> I suggest adding a line that says that this class is used by bindings.

I think we shouldn't document obvious things as that's very little added value. Any IDE can show you where the class is used.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1986920125

From mstrauss at openjdk.org  Mon Mar 10 10:14:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 10:14:07 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor
In-Reply-To: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
Message-ID: <9c4duLq9qOoOCusuEczGJNPfZ0HN4LTmnwlx_xDYEYA=.7600b3ca-5b6a-40f5-8bef-60542bc5230d@github.com>

On Wed, 5 Mar 2025 18:40:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> - synchronized `EventType::register()` method
> - simplified internal constructor which is only used for `EventType.ROOT`
> 
> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
> 
> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.

modules/javafx.base/src/main/java/javafx/event/EventType.java line 136:

> 134:      * Internal constructor that skips various checks
> 135:      */
> 136:     private EventType(String name, boolean marker) {

If you name the paramter `ignored`, IntelliJ doesn't flag it as unused.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1729#discussion_r1986985183

From jhendrikx at openjdk.org  Mon Mar 10 10:44:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 10:44:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <GZS2937V-Mf2--0Vhym2Xz-ihQdzMYo0euzruVL_S_A=.8bb52270-3201-4062-b177-854316d07fbe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <GZS2937V-Mf2--0Vhym2Xz-ihQdzMYo0euzruVL_S_A=.8bb52270-3201-4062-b177-854316d07fbe@github.com>
Message-ID: <Dzj5BAa0KNVnIUmq-Fo3Mcd-hR21qsWf9ivLYtO0bW4=.b476b351-93d7-4fbf-97c8-c2edc48ea9c0@github.com>

On Mon, 10 Mar 2025 09:27:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Small fixes from review comments
>>  - Use switch expression where reasonable
>>  - Update docs regarding NullPointerExceptions
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 174:
> 
>> 172:                  */
>> 173: 
>> 174:                 throw new StackOverflowError("non-converging value detected in value modifying listeners on " + observableValue + "; original value was: " + oldValue);
> 
> We shouldn't throw errors, even if that's what the old implementation would implicitly do (not that it matters, no sane application would ever try to catch a `StackOverflowError` as part of its normal control flow). I think a `RuntimeException` is in order.
> 
> Also maybe make the message a bit clearer:
> `<observableValue> was changed during the invocation of multiple listeners, but the new values diverge [original value: <oldValue>]`

Maybe it should only be a warning log. Any exception a listener may throw is currently only logged so other listeners may still continue to work correctly.  Throwing an `Error` was a nice way around that, but does potentially leave some listeners uninformed of a change or invalidation (same as `ExpressionHelper` in that regard).

If we go for a runtime exception, I'd need to allow the exception to pass through, but the same thing still applies that breaking it off with an exception may leave some listeners uninformed.  So I think we need to decide, how "bad" is this problem, and does it warrant terminating the application.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1987032716

From kcr at openjdk.org  Mon Mar 10 12:39:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Mar 2025 12:39:01 GMT
Subject: RFR: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin [v7]
In-Reply-To: <aEFUePWuhApJhQLHET-YK-pCv-TlHivetG5mw0BjdVI=.441daa03-25fb-4982-869b-0936e14377b6@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
 <aEFUePWuhApJhQLHET-YK-pCv-TlHivetG5mw0BjdVI=.441daa03-25fb-4982-869b-0936e14377b6@github.com>
Message-ID: <UZNHtpYls0BvmhT2QqE_7WHlYWygEkynUDdEMjZ24F8=.128dfaef-1620-48a3-99a3-9be8ce3417d9@github.com>

On Fri, 7 Mar 2025 17:56:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - enforced fx application thread
>> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
>> - clarified `ComboBoxBase::show`
>> - added a headful test `TestThreadingRestrictions`
>
> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - indent
>  - indent

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1717#pullrequestreview-2670804014

From mstrauss at openjdk.org  Mon Mar 10 13:38:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 13:38:07 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
Message-ID: <z7mo-hdSaNCzw3Srsot2ikrE8jwn-TzaT9HLgU2RI08=.96ab3171-9046-42c9-a982-3b6ff9e44b65@github.com>

On Mon, 10 Mar 2025 08:48:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small fixes from review comments
>  - Use switch expression where reasonable
>  - Update docs regarding NullPointerExceptions

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 108:

> 106:         int initialProgress = progress;  // save as it will be modified soon
> 107:         int invalidationListenersSize = invalidationListenersSize();
> 108:         int maxInvalidations = wasLocked ? Math.min(initialProgress + 1, invalidationListenersSize) : invalidationListenersSize;

You could break up the very long lines:

Suggestion:

        int maxInvalidations = wasLocked
            ? Math.min(initialProgress + 1, invalidationListenersSize)
            : invalidationListenersSize;

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 126:

> 124: 
> 125:         int changeListenersSize = changeListenersSize();
> 126:         int maxChanges = wasLocked ? Math.min(initialProgress + 1 - invalidationListenersSize, changeListenersSize) : changeListenersSize;

And here:

Suggestion:

        int maxChanges = wasLocked
            ? Math.min(initialProgress + 1 - invalidationListenersSize, changeListenersSize)
            : changeListenersSize;

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1987292740
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1987300050

From mstrauss at openjdk.org  Mon Mar 10 13:38:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 13:38:07 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <Dzj5BAa0KNVnIUmq-Fo3Mcd-hR21qsWf9ivLYtO0bW4=.b476b351-93d7-4fbf-97c8-c2edc48ea9c0@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <GZS2937V-Mf2--0Vhym2Xz-ihQdzMYo0euzruVL_S_A=.8bb52270-3201-4062-b177-854316d07fbe@github.com>
 <Dzj5BAa0KNVnIUmq-Fo3Mcd-hR21qsWf9ivLYtO0bW4=.b476b351-93d7-4fbf-97c8-c2edc48ea9c0@github.com>
Message-ID: <g9aDxKO0WqcXrugOfbUb30nk-szyfX5b4Pw35vb90z4=.4e3c4067-643c-413f-8a03-07457b85f7d5@github.com>

On Mon, 10 Mar 2025 10:41:25 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerList.java line 174:
>> 
>>> 172:                  */
>>> 173: 
>>> 174:                 throw new StackOverflowError("non-converging value detected in value modifying listeners on " + observableValue + "; original value was: " + oldValue);
>> 
>> We shouldn't throw errors, even if that's what the old implementation would implicitly do (not that it matters, no sane application would ever try to catch a `StackOverflowError` as part of its normal control flow). I think a `RuntimeException` is in order.
>> 
>> Also maybe make the message a bit clearer:
>> `<observableValue> was changed during the invocation of multiple listeners, but the new values diverge [original value: <oldValue>]`
>
> Maybe it should only be a warning log. Any exception a listener may throw is currently only logged so other listeners may still continue to work correctly.  Throwing an `Error` was a nice way around that, but does potentially leave some listeners uninformed of a change or invalidation (same as `ExpressionHelper` in that regard).
> 
> If we go for a runtime exception, I'd need to allow the exception to pass through, but the same thing still applies that breaking it off with an exception may leave some listeners uninformed.  So I think we need to decide, how "bad" is this problem, and does it warrant terminating the application.

Is it possible to ignore the listener that incompatibly changed the value from Y back to X?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1987297519

From angorya at openjdk.org  Mon Mar 10 14:24:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 14:24:14 GMT
Subject: Integrated: 8350048: Enforce threading restrictions for show and hide
 methods in Window, Control, and Skin
In-Reply-To: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
References: <_H0gauNpMWXXEsDCPO_nfT7cZJUNmycjA0HnHmpCIeE=.1765e732-66e8-4f11-838d-5b45373f5d5f@github.com>
Message-ID: <IGcbNyRGCj7tTDnZhfws-vz7Zdh0vJt4St5g_YpCpKA=.c56718e8-f30e-420a-b482-fe0d6d8abfb0@github.com>

On Wed, 19 Feb 2025 20:39:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> - enforced fx application thread
> - clarify doc where an `IllegalStateException` can get thrown, such as hide() and show()
> - clarified `ComboBoxBase::show`
> - added a headful test `TestThreadingRestrictions`

This pull request has now been integrated.

Changeset: b5f76ad4
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/b5f76ad4fb2039cb1d175ff00ec1a38c4e9dd233
Stats:     480 lines in 13 files changed: 425 ins; 28 del; 27 mod

8350048: Enforce threading restrictions for show and hide methods in Window, Control, and Skin

Reviewed-by: kcr, mstrauss

-------------

PR: https://git.openjdk.org/jfx/pull/1717

From angorya at openjdk.org  Mon Mar 10 14:26:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 14:26:08 GMT
Subject: Integrated: 8351368: RichTextArea: exception pasting from Word
In-Reply-To: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
References: <TkdkRBiz0HxpvF1xjuVFnq94n0vSad8ALHO1kbMFYeQ=.607e7e03-656e-4649-9429-39c28dff98eb@github.com>
Message-ID: <5yUW1qQOqJSObCEIn26-D6Z8DSNPO10W0Ri00RN90QM=.bc844dad-28e8-42b9-b7dd-5467661ed72c@github.com>

On Thu, 6 Mar 2025 23:16:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The original code used String attribute keys.
> 
> I'd like to backport this fix to jfx24u.

This pull request has now been integrated.

Changeset: 1c3cfcb8
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8351368: RichTextArea: exception pasting from Word

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1731

From angorya at openjdk.org  Mon Mar 10 14:31:33 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 14:31:33 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v2]
In-Reply-To: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
Message-ID: <QaCCKBZ_tWPQqB2Bxt-NmgldjevpqVmbpEg__Ruv6k0=.6969ba9c-8e41-4e4f-b597-85a1ccec8a5d@github.com>

> - synchronized `EventType::register()` method
> - simplified internal constructor which is only used for `EventType.ROOT`
> 
> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
> 
> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - ignored
 - Merge remote-tracking branch 'origin/master' into 8351038.event.type
 - test
 - synchronized

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1729/files
  - new: https://git.openjdk.org/jfx/pull/1729/files/5492c550..552a645d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1729&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1729&range=00-01

  Stats: 866 lines in 23 files changed: 802 ins; 28 del; 36 mod
  Patch: https://git.openjdk.org/jfx/pull/1729.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1729/head:pull/1729

PR: https://git.openjdk.org/jfx/pull/1729

From angorya at openjdk.org  Mon Mar 10 15:07:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 15:07:43 GMT
Subject: [jfx24u] RFR: 8351368: RichTextArea: exception pasting from Word
Message-ID: <aRGaLV8zJIeK9YFQYM1d4gKYy9r3-17Y0uatd-CHsiw=.c41d765d-78f6-4722-8745-4afd897097ea@github.com>

Clean backport of https://github.com/openjdk/jfx/pull/1731

-------------

Commit messages:
 - Backport 1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b

Changes: https://git.openjdk.org/jfx24u/pull/11/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=11&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351368
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx24u/pull/11.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/11/head:pull/11

PR: https://git.openjdk.org/jfx24u/pull/11

From angorya at openjdk.org  Mon Mar 10 15:16:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 15:16:04 GMT
Subject: [jfx24u] Integrated: 8351368: RichTextArea: exception pasting from
 Word
In-Reply-To: <aRGaLV8zJIeK9YFQYM1d4gKYy9r3-17Y0uatd-CHsiw=.c41d765d-78f6-4722-8745-4afd897097ea@github.com>
References: <aRGaLV8zJIeK9YFQYM1d4gKYy9r3-17Y0uatd-CHsiw=.c41d765d-78f6-4722-8745-4afd897097ea@github.com>
Message-ID: <GG4Iv7623NFOwtI7rFFfd_5snp5OhIaeZ4BcZT-HPj0=.04ab6061-4f02-4d1b-8c08-b535428c5179@github.com>

On Mon, 10 Mar 2025 15:00:32 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Clean backport of https://github.com/openjdk/jfx/pull/1731

This pull request has now been integrated.

Changeset: 8dd8347c
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/8dd8347cdf00077e71e2e21b2bbe243bb39cd6e1
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8351368: RichTextArea: exception pasting from Word

Backport-of: 1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b

-------------

PR: https://git.openjdk.org/jfx24u/pull/11

From angorya at openjdk.org  Mon Mar 10 16:12:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 16:12:15 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
Message-ID: <-JxgfW5APh-jRU4wPhBR8qtwWvpK365To1mNTfcFBmI=.97341139-3dd5-4b5f-9c5f-488836e690f9@github.com>

On Sat, 8 Mar 2025 08:23:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - 25 25
>>  - Merge branch 'master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge branch 'master' into ag.text.layout.api
>>  - segments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 256:
> 
>> 254:      * @return the caret geometry
>> 255:      */
>> 256:     public float[] getCaretGeometry(int offset, boolean leading);
> 
> Does this method throw any exceptions? If so, please specify.

This method does not throw any exceptions, so none are specified.

> modules/javafx.graphics/src/main/java/com/sun/javafx/scene/text/TextLayout.java line 271:
> 
>> 269:      * @param client the callback to invoke for each rectangular shape
>> 270:      */
>> 271:     public void getRange(int start, int end, int type, GeometryCallback client);
> 
> Does this method throw any exceptions?

no.

> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismCaretInfo.java line 54:
> 
>> 52:     public String toString() {
>> 53:         StringBuilder sb = new StringBuilder();
>> 54:         sb.append("PrismCaretInfo{parts=[");
> 
> I think you shouldn't leak implementation details via the `toString()` method (the name of the implementing class, as well as `parts=`, which is not a term that appears in the API). Maybe just drop `PrismCaretInfo{parts=` entirely.

makes sense.

On a related note, we don't seem to have a consistent standard for toString() output (probably no one does!), so maybe it's worth polling the devs about it.

Standardized log output might be useful when one has to go through masses of old/transient logs, or when scraping the logs for analytics.  A JSON output might be useful since it offers a cheap structured form, although it suffers from two issues: verbosity and difficulty to encode binary data and object types easily.

Any ideas?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987607054
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987609067
PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987602663

From jhendrikx at openjdk.org  Mon Mar 10 16:17:13 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 16:17:13 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
Message-ID: <bBEOE0H_74oLGod1Djn15cehvIkdmoCGWB4UUg7fVXs=.9a4450e8-79d4-49cf-8716-76d472df42e7@github.com>

On Mon, 10 Mar 2025 08:48:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small fixes from review comments
>  - Use switch expression where reasonable
>  - Update docs regarding NullPointerExceptions

> Is it possible to ignore the listener that incompatibly changed the value from Y back to X?

@mstr2 I'm not entirely sure what you mean here. But let me give a few options.

When there's two listeners that can't reach agreement, the sequence of events looks like this:

1. Value was changed from W to X (old value is set to W, and current value is X at this level)
2. First listener called with W -> X -- listener code **modifies** value to Y
    1. Nested loop starts that notifies max 1 listener (as we only notified one so far). Old value is set to X.
    2. First listener is called again but now with X -> Y -- listener does nothing this time
    3. Nested loop ends
3. Nested loop completion is detected; current value is fetched which now becomes Y for this level, old value stays at W
4. Second listener is called with W -> Y -- listener code **modifies** value to X
    1. Nested loop starts that notifies max 2 listeners (as we notified two so far). Old value is set to Y.
    2. First listener is called for a third time but now with Y -> X -- listener code **modifies** value to Y
        1. Another nested loop starts with max 1 listener. Old value is set to X
        2. First listener is called for a fourth time but now with X -> Y -- listener does nothing this time
        3. Nested loop ends
    3. Nested loop completion is detected; current value is fetched which now becomes Y for this level, old value is also Y **(!!)**
    4. Can't call second listener (it would be Y -> Y) ... second listener (that previous set value to X) may now think value is still X...
    5. This resulted in a `StackOverflowError` in old code, so we throw that...
5. We never get here, so any further listeners are now in the dark as to the current value...

So as to your question, it seems that you're asking if we could ignore what the listener is doing in step 4.ii -- here the listener is changing the value back that eventually leads to a problem.  However, we only notice that this happened in step 4.iii -- the property has already been modified by then.  Are you asking if we could change the property back again (using `setValue(X)`)?  That would be really tricky, as it would just trigger another nested notification loop...

Or perhaps you are asking if we can just ignore 4.iv and not do 4.v ?  That's what the code did a few changes ago, but which would leave you in the dark that there is conflicting changes happening (whereas with `ExpressionHelper` this would lead to the `StackOverflowError` -- not perfect, but at least you're informed...)

Or perhaps you meant something else?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2711123705

From angorya at openjdk.org  Mon Mar 10 16:30:25 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 16:30:25 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v19]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <CNhyKGAUbiJVYJBSy0T50Yl7HM5Cv6YjTWYdyySoL-g=.d88a999d-cbaf-4bc6-986a-fe94c3a8662b@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:

 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - 25 25
 - Merge branch 'master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge branch 'master' into ag.text.layout.api
 - ... and 34 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...0ad6f66d

-------------

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=18
  Stats: 1524 lines in 14 files changed: 1448 ins; 21 del; 55 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Mon Mar 10 16:30:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 16:30:27 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v18]
In-Reply-To: <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <ppcFw0NuNVM7qPKpj8Cc_yvQcGQzybEcZSbnNWkle0Q=.b5845b2e-904b-4c17-ae6d-1efabc1b0930@github.com>
 <NwrEfhAEBt-XQ34Qsdkr-QFsxgFizTfS9wHaydJgNKc=.0195a686-b992-4a4d-bc3a-e4f1b6796fae@github.com>
Message-ID: <hbxhpPUmmm1kH63yJKlB0ZKw_Q8vKnJdqVYMKmqLt3s=.48ae2127-4a07-4d51-9640-a855496853dd@github.com>

On Sat, 8 Mar 2025 08:29:19 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - 25 25
>>  - Merge branch 'master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge branch 'master' into ag.text.layout.api
>>  - segments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - ... and 32 more: https://git.openjdk.org/jfx/compare/fc770fb9...0f94efdd
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/LayoutInfo.java line 41:
> 
>> 39:  * @since 25
>> 40:  */
>> 41: public abstract class LayoutInfo {
> 
> Any exceptions thrown by methods of this class?

only `public abstract TextLineInfo getTextLine(int index, boolean includeLineSpacing);`

(added)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987635998

From angorya at openjdk.org  Mon Mar 10 16:35:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 16:35:28 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v20]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <_gu9C3BMcsYID4ESSA5p93PS4r07Miy9kFEW-eHAOSg=.767284e4-98d9-4901-a8e9-6d3a83b36bef@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  tests

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/0ad6f66d..9d499c16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=19
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=18-19

  Stats: 30 lines in 2 files changed: 30 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From mstrauss at openjdk.org  Mon Mar 10 17:07:11 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 17:07:11 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v19]
In-Reply-To: <CNhyKGAUbiJVYJBSy0T50Yl7HM5Cv6YjTWYdyySoL-g=.d88a999d-cbaf-4bc6-986a-fe94c3a8662b@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <CNhyKGAUbiJVYJBSy0T50Yl7HM5Cv6YjTWYdyySoL-g=.d88a999d-cbaf-4bc6-986a-fe94c3a8662b@github.com>
Message-ID: <F5PpgyrfIjazlzuHd5wCo0wsgGbbayS3ZB_gRNfvYXQ=.2b9a840b-f2c5-4d0a-a6cf-bc26927da6d9@github.com>

On Mon, 10 Mar 2025 16:30:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Please refer to
>> 
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
>> 
>> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
>> 
>> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
>> 
>> 
>>     /**
>>      * Obtains the snapshot of the current text layout information.
>>      * @return the layout information
>>      * @since 25
>>      */
>>     public final LayoutInfo getLayoutInfo()
>> 
>> 
>> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
>> 
>> - caret information
>> - text lines: offsets and bounds
>> - overall layout bounds
>> - text selection geometry
>> - strike-through geometry
>> - underline geometry
>> 
>> 
>> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
>> 
>> 
>>     /**
>>      * Returns the shape for the strike-through in local coordinates.
>>      *
>>      * @param start the beginning character index for the range
>>      * @param end the end character index (non-inclusive) for the range
>>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>>      * @since 25
>>      */
>>     public final PathElement[] strikeThroughShape(int start, int end)
>> 
>> 
>> 
>> 
>> ## WARNING
>> 
>> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
>> 
>> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
>> 
>> 
>> 
>> ## Testing
>> 
>> The new APIs can be visually tested using the Monkey Tester on this branch:
>> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
>> 
>> in the Text and TextFlow pages:
>> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
>> 
>> Two very basic headful tests have been added.
>> 
>> 
>> ## See Also
>> 
>> https://github.com/FXMisc/RichTextFX/pull/1246
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - 25 25
>  - Merge branch 'master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>  - Merge branch 'master' into ag.text.layout.api
>  - ... and 34 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...0ad6f66d

modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 59:

> 57:      * @param index the line index
> 58:      * @return the bounds of the caret segment
> 59:      * @throws IndexOutOfBoundsException if the index is outside of the range if the index is out of range

I think this sentence repeats the same thing twice, maybe check again. You can probably just say `if the index is out of range {@code (...)}`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987698240

From martinfox656 at gmail.com  Mon Mar 10 17:10:19 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Mon, 10 Mar 2025 10:10:19 -0700
Subject: JVM crashes on macOS when entering too many nested event loops
In-Reply-To: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
Message-ID: <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>

Hi Christopher,

I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack. 
I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.

Martin

> On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Hello,
> 
> I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
> 
> As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
> 
> Best
> Christopher Schnick<hs_err_pid.txt>


From angorya at openjdk.org  Mon Mar 10 17:13:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 17:13:01 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v21]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <3laEi6L28LsPvXWVTjp9qrom1okh9NDB2DLltJs6mLg=.613910bc-6524-4f95-b370-5c100cd64766@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  twice

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1596/files
  - new: https://git.openjdk.org/jfx/pull/1596/files/9d499c16..b7033cf6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=20
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=19-20

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Mon Mar 10 17:13:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 17:13:02 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v19]
In-Reply-To: <F5PpgyrfIjazlzuHd5wCo0wsgGbbayS3ZB_gRNfvYXQ=.2b9a840b-f2c5-4d0a-a6cf-bc26927da6d9@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
 <CNhyKGAUbiJVYJBSy0T50Yl7HM5Cv6YjTWYdyySoL-g=.d88a999d-cbaf-4bc6-986a-fe94c3a8662b@github.com>
 <F5PpgyrfIjazlzuHd5wCo0wsgGbbayS3ZB_gRNfvYXQ=.2b9a840b-f2c5-4d0a-a6cf-bc26927da6d9@github.com>
Message-ID: <oGyqFqcKXOswbubFbue64MfZee8pVdKvNSj2GrOvktk=.df2ecda9-fca5-48d9-9db1-823508c838ae@github.com>

On Mon, 10 Mar 2025 17:04:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
>> 
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - review comments
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - 25 25
>>  - Merge branch 'master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
>>  - Merge branch 'master' into ag.text.layout.api
>>  - ... and 34 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...0ad6f66d
>
> modules/javafx.graphics/src/main/java/javafx/scene/text/CaretInfo.java line 59:
> 
>> 57:      * @param index the line index
>> 58:      * @return the bounds of the caret segment
>> 59:      * @throws IndexOutOfBoundsException if the index is outside of the range if the index is out of range
> 
> I think this sentence repeats the same thing twice, maybe check again. You can probably just say `if the index is out of range {@code (...)}`.

daylight saving time strikes!
thanks for noticing.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1596#discussion_r1987705155

From mstrauss at openjdk.org  Mon Mar 10 17:25:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 10 Mar 2025 17:25:17 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <bBEOE0H_74oLGod1Djn15cehvIkdmoCGWB4UUg7fVXs=.9a4450e8-79d4-49cf-8716-76d472df42e7@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <bBEOE0H_74oLGod1Djn15cehvIkdmoCGWB4UUg7fVXs=.9a4450e8-79d4-49cf-8716-76d472df42e7@github.com>
Message-ID: <vV1odWqW5c1xoSI_8SrQvzYz4E3sv0Gp8kZHL_Bvyss=.9cc87bf1-7ae7-4a9d-89ce-ab2804953deb@github.com>

On Mon, 10 Mar 2025 16:14:36 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Or perhaps you are asking if we can just ignore 4.iv and not do 4.v ? That's what the code did a few changes ago, but which would leave you in the dark that there is conflicting changes happening (whereas with `ExpressionHelper` this would lead to the `StackOverflowError` -- not perfect, but at least you're informed...)

What if we didn't call back the second listener (as you said, it would probably result in an infinite loop), and logged an error instead (that's not without precedence, bindings also log errors)? It seems like this would still allow other listeners to receive notifications, while the "defective" listener would not.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2711312666

From jhendrikx at openjdk.org  Mon Mar 10 17:42:10 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 10 Mar 2025 17:42:10 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <vV1odWqW5c1xoSI_8SrQvzYz4E3sv0Gp8kZHL_Bvyss=.9cc87bf1-7ae7-4a9d-89ce-ab2804953deb@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <bBEOE0H_74oLGod1Djn15cehvIkdmoCGWB4UUg7fVXs=.9a4450e8-79d4-49cf-8716-76d472df42e7@github.com>
 <vV1odWqW5c1xoSI_8SrQvzYz4E3sv0Gp8kZHL_Bvyss=.9cc87bf1-7ae7-4a9d-89ce-ab2804953deb@github.com>
Message-ID: <LUM4B-nsrL7_EzAiaG4qL4Znw5Ff6EsDu-SSnMRcS4g=.91e2f232-7820-4ad1-9ee5-0d09669dfae4@github.com>

On Mon, 10 Mar 2025 17:22:16 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> What if we didn't call back the second listener (as you said, it would probably result in an infinite loop), and logged an error instead (that's not without precedence, bindings also log errors)? It seems like this would still allow other listeners to receive notifications, while the "defective" listener would not.

I'm fine with logging a warning/error instead.  If Nir also agrees, I can make the modifications.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2711355636

From andy.goryachev at oracle.com  Mon Mar 10 17:51:36 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Mon, 10 Mar 2025 17:51:36 +0000
Subject: JVM crashes on macOS when entering too many nested event loops
In-Reply-To: <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
Message-ID: <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>

This looks to me like it might be hitting the (native) thread stack size limit.

c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:


     * An application may enter several nested loops recursively. There's no

     * limit of recursion other than that imposed by the native stack size.


-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com>
Date: Monday, March 10, 2025 at 10:10
To: Christopher Schnick <crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: JVM crashes on macOS when entering too many nested event loops
Hi Christopher,

I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.

Martin

> On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
>
> Hello,
>
> I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>
> As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>
> Best
> Christopher Schnick<hs_err_pid.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250310/05f620b2/attachment-0001.htm>

From angorya at openjdk.org  Mon Mar 10 18:27:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 18:27:12 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v51]
In-Reply-To: <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
Message-ID: <ryXr4vikGvTi7Bm_zp-HA1jIYxABaZxHCphqdcDG344=.cb999b4f-c378-44bc-8612-1ed46d8e5db4@github.com>

On Fri, 21 Feb 2025 02:44:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove HeaderButtonOverlay.allowRtl

1. you may want to sync up with the latest master
2. on Windows, the toolbar buttons do not initially appear for EXTENDED and EXTENDED_UTILITY.  (They seem to re-appear after the focus is lost):

![Screenshot 2025-03-10 112110](https://github.com/user-attachments/assets/8967ee2b-0da6-4a5c-9cdf-5347ce3f065f)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2711462803

From angorya at openjdk.org  Mon Mar 10 18:49:08 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 18:49:08 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v51]
In-Reply-To: <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
Message-ID: <Sw9ZdYC4lYigAAQkg_SNZybuEZ18zzsEdGfiFKAWmUg=.1920eae2-f390-4c6e-8639-ad828913101c@github.com>

On Fri, 21 Feb 2025 02:44:47 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove HeaderButtonOverlay.allowRtl

Also on Windows, when the button do appear, their size seems to differ from the native:

![Screenshot 2025-03-10 111543](https://github.com/user-attachments/assets/9346bf63-ad6c-4cbb-9d55-c559dd02e252)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2711515824

From angorya at openjdk.org  Mon Mar 10 20:30:43 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 10 Mar 2025 20:30:43 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v4]
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <BdaT6ghnr5NSs0EL1u2WyFxphagRmHcos8ZzsPOibFw=.20c1dfbe-444c-4fe4-bb9c-d5fdfc51aadd@github.com>

> Summary
> -------
> 
> Adds a thread check to a number of `Platform` methods:
> 
> accessibilityActiveProperty()
> getPreferences()
> isAccessibilityActive()
> 
> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
> 
> Problem
> -------
> 
> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
> 
> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
> 
> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
> 
> Solution
> --------
> 
> Fail each method fast with an  `IllegalStateException` if called from a background thread.
> 
> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  get preferences

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1728/files
  - new: https://git.openjdk.org/jfx/pull/1728/files/0f39382c..e9bb3403

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=02-03

  Stats: 6 lines in 2 files changed: 5 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1728/head:pull/1728

PR: https://git.openjdk.org/jfx/pull/1728

From kcr at openjdk.org  Mon Mar 10 22:42:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Mar 2025 22:42:16 GMT
Subject: [jfx24u] RFR: 8351602: Change JavaFX release version to 24.0.2 in
 jfx24u
Message-ID: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>

Bump version number to 24.0.2.

I plan to integrate this some time tomorrow morning (Pacific).

-------------

Commit messages:
 - 8351602: Change JavaFX release version to 24.0.2 in jfx24u

Changes: https://git.openjdk.org/jfx24u/pull/12/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=12&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351602
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx24u/pull/12.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/12/head:pull/12

PR: https://git.openjdk.org/jfx24u/pull/12

From kcr at openjdk.org  Mon Mar 10 22:42:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 10 Mar 2025 22:42:16 GMT
Subject: [jfx24u] RFR: 8351602: Change JavaFX release version to 24.0.2 in
 jfx24u
In-Reply-To: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
References: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
Message-ID: <yKeN0nAgCSlsb-TgdXX-7x80yIHyXNKLajt6upyPeow=.7bbc6323-d6bb-4a9e-96ad-43f4754823ca@github.com>

On Mon, 10 Mar 2025 22:35:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump version number to 24.0.2.
> 
> I plan to integrate this some time tomorrow morning (Pacific).

Reviewer: @johanvos

Since this is not a backport, it needs both a Review and a Maintainer approval.

-------------

PR Comment: https://git.openjdk.org/jfx24u/pull/12#issuecomment-2712002774

From nlisker at openjdk.org  Tue Mar 11 02:37:04 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 11 Mar 2025 02:37:04 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <XGLu7DaV7i_X_N3UIJL-7BomTubF3BEoC9J5AQ41Zn0=.edb57bfc-c74c-41c8-be55-3c95b61c52eb@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <XGLu7DaV7i_X_N3UIJL-7BomTubF3BEoC9J5AQ41Zn0=.edb57bfc-c74c-41c8-be55-3c95b61c52eb@github.com>
Message-ID: <SD1bst8LgeiXJuxhZ18501TjAckGnbSX8D7js--E8ak=.9da69d2c-dee4-497f-8b94-f1dc16e22c18@github.com>

On Mon, 10 Mar 2025 08:42:07 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 53:
>> 
>>> 51:  * within listener list. If possible use {@link ListenerManager}, as it has less
>>> 52:  * storage requirements and is faster.
>>> 53:  *
>> 
>> I suggest adding a line that says that this class is used by properties.
>
> That doesn't seem like something you should be adding to the docs I think?

Up to you. I thought it would make it easier on anyone learning the implementations if they understood why 2 are needed (one that stores the value and one that relies on the value being stored elsewhere).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1988273974

From crschnick at xpipe.io  Tue Mar 11 02:47:10 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 11 Mar 2025 03:47:10 +0100
Subject: JVM crashes on macOS when entering too many nested event loops
In-Reply-To: <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <85df75dc-13cd-4369-b051-6e3ed05863e1@xpipe.io>

Our code and some libraries do enter some nested event loops at a few 
places when it makes sense, but we didn't do anything to explicitly 
provoke this, this occurred naturally in our application. So it would be 
nice if JavaFX could somehow guard against this, especially since 
crashing the JVM is probably the worst thing that can happen.

I looked at the documentation, but it seems like the public API at 
Platform::enterNestedEventLoop does not mention this.
 From my understanding, the method Platform::canStartNestedEventLoop is 
potentially the right method to indicate to the caller that the limit is 
close by returning false.
And even if something like an exception is thrown when a nested event 
loop is started while it is close to the limit, that would still be much 
better than a direct crash.

Best
Christopher Schnick

On 10/03/2025 18:51, Andy Goryachev wrote:
>
> This looks to me like it might be hitting the (native) thread stack 
> size limit.
>
> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>
> ???? * An application may enter several nested loops recursively. 
> There's no
>
> ???? * limit of recursion other than that imposed by the native stack 
> size.
>
> -andy
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Martin 
> Fox <martinfox656 at gmail.com>
> *Date: *Monday, March 10, 2025 at 10:10
> *To: *Christopher Schnick <crschnick at xpipe.io>
> *Cc: *OpenJFX <openjfx-dev at openjdk.org>
> *Subject: *Re: JVM crashes on macOS when entering too many nested 
> event loops
>
> Hi Christopher,
>
> I was able to reproduce this crash. I wrote a small routine that 
> recursively calls itself in a runLater block and then enters a nested 
> event loop. The program crashes when creating loop 254. I?m not sure 
> where that limit comes from so it?s possible that consuming some other 
> system resource could lower it. I couldn?t see any good way to 
> determine how many loops are active by looking at the crash report 
> since it doesn?t show the entire call stack.
> I did a quick trial on Linux and was able to create a lot more loops 
> (over 600) but then started seeing erratic behavior and errors coming 
> from the Java VM. The behavior was variable unlike on the Mac which 
> always crashes when creating loop 254.
>
> Martin
>
> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> 
> wrote:
> >
> > Hello,
> >
> > I have attached a JVM fatal error log that seemingly was caused by 
> our JavaFX application entering too many nested event loops, which 
> macOS apparently doesn't like.
> >
> > As far as I know, there is no upper limit defined on how often an 
> event loop can be nested, so I think this is a bug that can occur in 
> rare situations.
> >
> > Best
> > Christopher Schnick<hs_err_pid.txt>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250311/13a03366/attachment-0001.htm>

From nlisker at openjdk.org  Tue Mar 11 02:51:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 11 Mar 2025 02:51:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
Message-ID: <8A3yqfHTOdeADGmSEaXCJOCDhqojMVDcq-R1t79r3PA=.ff372cfe-4b3e-4081-84ec-d243d298ce76@github.com>

On Mon, 10 Mar 2025 08:48:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Small fixes from review comments
>  - Use switch expression where reasonable
>  - Update docs regarding NullPointerExceptions

If we can know that the values are going to diverge then logging an error instead of throwing it is fine. However, if they are trying to find a common divisor (as in John's example above), it could take many callbacks for the final value to settle.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2712375318

From nlisker at openjdk.org  Tue Mar 11 02:57:06 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Tue, 11 Mar 2025 02:57:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <ROxUcok2zDBAZX5kLpuaMEm_gwrc39vZ34oDeZHeDCg=.381965e6-60c1-4a77-971a-b0d5f6c66286@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <ROxUcok2zDBAZX5kLpuaMEm_gwrc39vZ34oDeZHeDCg=.381965e6-60c1-4a77-971a-b0d5f6c66286@github.com>
Message-ID: <Nh5DeV0qhsa4DbD5V8v2wZ4mMfplCLDw0jKiPZ9BlLc=.ae328419-0489-44fd-8f65-4eba2148f56d@github.com>

On Mon, 10 Mar 2025 07:37:27 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> > First part of the review.
> > There are several class (and their methods) that are `public`, but are only used in their package and can just have package-access: `OldValueCachingListenerList` `ListenerManagerBase` `ListenerListBase` `ListenerList` `ArrayManager`
> > If they are `public` because of tests, please add a comment like "public for testing purpose"
> 
> I understand that making a **method** public that shouldn't be should be documented as such, but what's against having public classes in non-exported packages even if just for testing purposes? This is done widely through out FX already.
> 
> Also these classes are well documented, and there's no reason they could not be used outside their package, even if they currently are not.

I tend to restrict visibility unless necessary, especially when some classes function as helper classes, but it's fine to leave as is.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2712389612

From jhendrikx at openjdk.org  Tue Mar 11 06:37:08 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 06:37:08 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <8A3yqfHTOdeADGmSEaXCJOCDhqojMVDcq-R1t79r3PA=.ff372cfe-4b3e-4081-84ec-d243d298ce76@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <8A3yqfHTOdeADGmSEaXCJOCDhqojMVDcq-R1t79r3PA=.ff372cfe-4b3e-4081-84ec-d243d298ce76@github.com>
Message-ID: <GFGb4MLBPU1IzI2QlYw0TymOeyfHRwo823anN75pm94=.d6146fd4-b186-4ad6-a8a1-04f532040496@github.com>

On Tue, 11 Mar 2025 02:48:50 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> If we can know that the values are going to diverge then logging an error instead of throwing it is fine. However, if they are trying to find a common divisor (as in John's example above), it could take many callbacks for the final value to settle.

I'm unsure what you are saying here.  The common divisor example would not log a warning if I place the warning log in the same location as the SOE.

As for the behavior of multiple listeners, we can never really know for certain if they will eventually agree.  I mean, even the examples with `ExpressionHelper` can avoid a SOE **if** they can change their minds after 100 back-and-forth attempts, and do something else.  The same applies for this implementation.  If listeners are non-deterministic (same input does not lead to same output, by using randomness for example) then we can never be sure if they will reach agreement.

So, aside from letting this "escalate" into a SOE (where the JVM simply gives up) there is no real way to be sure that the values won't converge at some point.  The check I added is making the assumption that listeners are deterministic, but they don't have to be.  Then again, we're again approaching super rare exotic edge cases, that `ExpressionHelper` is not handling either (if it is even possible to handle this).  A non-deterministic listener that also modifies the value of the very property it is monitoring is not something we should have to worry about.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2712831349

From jhendrikx at openjdk.org  Tue Mar 11 06:45:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 06:45:58 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener...

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Break up long lines of code

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/3c385444..b0263704

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=12
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=11-12

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From jhendrikx at openjdk.org  Tue Mar 11 07:12:07 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 07:12:07 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <SD1bst8LgeiXJuxhZ18501TjAckGnbSX8D7js--E8ak=.9da69d2c-dee4-497f-8b94-f1dc16e22c18@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <XGLu7DaV7i_X_N3UIJL-7BomTubF3BEoC9J5AQ41Zn0=.edb57bfc-c74c-41c8-be55-3c95b61c52eb@github.com>
 <SD1bst8LgeiXJuxhZ18501TjAckGnbSX8D7js--E8ak=.9da69d2c-dee4-497f-8b94-f1dc16e22c18@github.com>
Message-ID: <0Zim-ODL6AjzCW3Ro9Oi0SCC7PfBxBE3LIf6gcPdhKY=.b58ecaa3-fd4d-4d5c-bf27-bf22dd432307@github.com>

On Tue, 11 Mar 2025 02:34:50 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> That doesn't seem like something you should be adding to the docs I think?
>
> Up to you. I thought it would make it easier on anyone learning the implementations if they understood why 2 are needed (one that stores the value and one that relies on the value being stored elsewhere).

I can always put a comment outside the docs.  I think the docs (in `OldValueCachingListenerManager`) are quite clear already though why you'd use one or the other.  Note that in an ideal world, we would never need `OldValueCachingListenerManager`. I mean, it is currently used for **properties** the exact thing you'd expect to have a readily available old value. However, a big design flaw in properties makes it impossible to do this:

The design flaw is the **use** of a protected `fireValueChangedEvent` method within the property, that has an **implementation** and is **not final**.  This is poor design, because:

- You can't change the implementation, as subclasses may call `super.fireValueChangedEvent`
- You can't change **when** you call it, as subclasses may be overriding it to be "aware" of changes
- You can't even provide the default implementation somewhere else, then call `fireValueChangedEvent` as subclasses may be purposely disabling or altering the default implementation

So, theoretically, I can **easily** provide the old value for properties, but it means I have to do one of the following:
- Execute the default implementation (but now with old value support) regardless of whether `fireValueChangedEvent` was overridden -- would break code that overrides this method to block the default implementation
- Change the signature of `fireValueChangedEvent` to accept a `T oldValue` -- can't do that, its `protected`
- Modify the default implementation to fetch the old value from somewhere to provide it -- can't do that as subclasses may be calling it at random, and they won't have the mechanism in place to provide the old value via something other than a parameter

You should never do all three of these for protected methods, as it makes the providing class fragile and tightly coupled with subclasses:

- Provide an implementation in a protected method.
- Make it non-final.
- Call it internally when its implementation is essential for correct operation.

Doing only two of these is fine:

- Providing an implementation and making it overridable is fine if the base class doesn't rely on it (i.e., it's just a helper).
- Providing an implementation that is final and using it internally is fine because subclasses can't alter the base class's behavior.
- Calling a non-final protected method with no expected implementation in the base class is also fine.

If we choose to address this at some point, to make properties more performant (with regards to listeners) and use less memory (when using a single change listener) it would mean a backwards incompatible change.  The change will mostly affect FX classes (as they rely on being able to both call `fireValueChangedEvent` as well as being able to override it) but it may affect 3rd parties as well as they can call and/or override it as well.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1988542989

From jvos at openjdk.org  Tue Mar 11 07:33:00 2025
From: jvos at openjdk.org (Johan Vos)
Date: Tue, 11 Mar 2025 07:33:00 GMT
Subject: [jfx24u] RFR: 8351602: Change JavaFX release version to 24.0.2 in
 jfx24u
In-Reply-To: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
References: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
Message-ID: <3HMO7oCmYvpr2DCP0_XEmG5jNsNoVmn7x1Ew4GKfIoc=.a99567da-c917-495d-ba50-faa213c62386@github.com>

On Mon, 10 Mar 2025 22:35:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump version number to 24.0.2.
> 
> I plan to integrate this some time tomorrow morning (Pacific).

Marked as reviewed by jvos (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx24u/pull/12#pullrequestreview-2673168449

From kcr at openjdk.org  Tue Mar 11 14:47:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 14:47:03 GMT
Subject: [jfx24u] Integrated: 8351602: Change JavaFX release version to 24.0.2
 in jfx24u
In-Reply-To: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
References: <Ro3U2aHeaOvMeURhTzOaxkL91o_cb0xUIbP_WK3qiC0=.377ae488-a05d-482c-91d5-83fc6bc1f5fb@github.com>
Message-ID: <w7hhWIHXqj_EK7uXtnIEP0jmKdBYB1jIfHbC_rRK2wY=.a1025252-72b8-4fde-88a7-d4fa8192ac83@github.com>

On Mon, 10 Mar 2025 22:35:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump version number to 24.0.2.
> 
> I plan to integrate this some time tomorrow morning (Pacific).

This pull request has now been integrated.

Changeset: 715457dc
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/715457dc87bdaa8fa53a099d445b0c9b1f5ede6b
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8351602: Change JavaFX release version to 24.0.2 in jfx24u

Reviewed-by: jvos

-------------

PR: https://git.openjdk.org/jfx24u/pull/12

From mstrauss at openjdk.org  Tue Mar 11 16:41:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 11 Mar 2025 16:41:24 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v51]
In-Reply-To: <ryXr4vikGvTi7Bm_zp-HA1jIYxABaZxHCphqdcDG344=.cb999b4f-c378-44bc-8612-1ed46d8e5db4@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
 <ryXr4vikGvTi7Bm_zp-HA1jIYxABaZxHCphqdcDG344=.cb999b4f-c378-44bc-8612-1ed46d8e5db4@github.com>
Message-ID: <RpkN19xT8Au2Z4tCwn6BMjjVhd_cn0hfQYkNTpVNpGM=.c5c9a05d-a694-4a95-986f-677bc005f613@github.com>

On Mon, 10 Mar 2025 18:24:30 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> I did find one regression:
> 
> On Windows, the toolbar buttons do not initially appear for EXTENDED and EXTENDED_UTILITY. (They seem to re-appear after the focus is lost):

It's working as designed. The reason here is that you didn't include a `HeaderBar` control, which means that the header buttons are not accounted for in layout. In addition to that, the scene background is transparent, which according to `Utils.calculateAverageBrightness(Color.TRANSPARENT)` is a dark color. That means that the glyphs of the header buttons are colored with a contrasting white (due to the "dark" background). This is why the glyphs are barely visible, but become visible when changed to a gray unfocused style.

The fix is to set the scene background to a color that resembles the header bar background (in this case, white). More details are in the `StageStyle.EXTENDED` documentation.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2715015226

From mstrauss at openjdk.org  Tue Mar 11 16:47:45 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 11 Mar 2025 16:47:45 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v52]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <KVN090-L-XlGMQNfziHrIIF2UNg6sUlzMonYYbFmrbw=.fe64aec5-d0da-4c58-b3a0-4dfba84ca0bb@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - Merge branch 'master' into feature/extended-window
 - remove HeaderButtonOverlay.allowRtl
 - minify button glyphs
 - typo
 - update copyright headers
 - Merge branch 'master' into feature/extended-window
 - Remove HeaderBarBase
 - Added HeaderBarBase.prefButtonHeight, removed Stage.initDefaultHeaderButtons
 - add "maximized" pseudo-class for custom maximize button
 - move StageTester to Tools menu
 - ... and 57 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...e6e81001

-------------

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=51
  Stats: 6376 lines in 73 files changed: 5698 ins; 499 del; 179 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From angorya at openjdk.org  Tue Mar 11 19:14:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 11 Mar 2025 19:14:10 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v52]
In-Reply-To: <KVN090-L-XlGMQNfziHrIIF2UNg6sUlzMonYYbFmrbw=.fe64aec5-d0da-4c58-b3a0-4dfba84ca0bb@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <KVN090-L-XlGMQNfziHrIIF2UNg6sUlzMonYYbFmrbw=.fe64aec5-d0da-4c58-b3a0-4dfba84ca0bb@github.com>
Message-ID: <7ZbkxS_J36HHoNhP4XgBdOPHNq0fFnb-YTcqQIbIjbM=.01246a08-0662-42b7-87ee-efc249c92506@github.com>

On Tue, 11 Mar 2025 16:47:45 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'master' into feature/extended-window
>  - remove HeaderButtonOverlay.allowRtl
>  - minify button glyphs
>  - typo
>  - update copyright headers
>  - Merge branch 'master' into feature/extended-window
>  - Remove HeaderBarBase
>  - Added HeaderBarBase.prefButtonHeight, removed Stage.initDefaultHeaderButtons
>  - add "maximized" pseudo-class for custom maximize button
>  - move StageTester to Tools menu
>  - ... and 57 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...e6e81001

Tested on macOS and Win 11 - looks good.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2675836391

From angorya at openjdk.org  Tue Mar 11 19:14:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 11 Mar 2025 19:14:11 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v51]
In-Reply-To: <RpkN19xT8Au2Z4tCwn6BMjjVhd_cn0hfQYkNTpVNpGM=.c5c9a05d-a694-4a95-986f-677bc005f613@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
 <ryXr4vikGvTi7Bm_zp-HA1jIYxABaZxHCphqdcDG344=.cb999b4f-c378-44bc-8612-1ed46d8e5db4@github.com>
 <RpkN19xT8Au2Z4tCwn6BMjjVhd_cn0hfQYkNTpVNpGM=.c5c9a05d-a694-4a95-986f-677bc005f613@github.com>
Message-ID: <3Btl3I3LdxiNnujF0iqxYes5v3EE_7LbSaIqM-E8XBU=.b4a841ef-3373-4018-927a-7e35a7cf423f@github.com>

On Tue, 11 Mar 2025 16:37:56 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> That means that the glyphs of the header buttons are colored with a contrasting white

oh yeah, I can see them.  thanks!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2715440703

From martinfox656 at gmail.com  Tue Mar 11 19:40:15 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Tue, 11 Mar 2025 12:40:15 -0700
Subject: JVM crashes on macOS when entering too many nested event loops
In-Reply-To: <85df75dc-13cd-4369-b051-6e3ed05863e1@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <85df75dc-13cd-4369-b051-6e3ed05863e1@xpipe.io>
Message-ID: <C82AA745-0359-42A6-96B2-962714E94C99@gmail.com>

I entered a bug https://bugs.openjdk.org/browse/JDK-8351733.

This crash doesn?t happen if you create nested event loops while processing events. I wrote a test app that started a new event loop on every mouse click and easily created over 400 nested loops. So we?re not pushing up against the native thread stack size limit, we?re running into an undocumented limit on the number of nested CFRunLoopRun calls. There?s a line to that effect in the crash log (which I overlooked for a while because I?m not used to crash logs being that helpful).

The bug is specific to the way the Mac handles runLater blocks and other internal uses of performSelectorOnMainThread. So far I can only reproduce this using Platform::runLater e.g. block A schedules runLater block B and then enters a nested event loop, block B schedules runLater block C and enters a nested event loop, and on and on. In a real app it?s also possible that some internal uses of performSelectorOnMainThread might be interacting with Platform::runLater calls in unexpected ways.

As far as I know here?s no way to ask the system what the CFRunLoopRun nesting limit is and no way to detect at runtime when we?ve hit it. The best we can do is maintain an internal counter and throw a runtime exception when it hits, say, 245 nested CFRunLoopRun calls. That at least would produce a very long but usable Java stack trace.

I could update Platform::canStartNestedEventLoop to detect this case but I?m not sure it would be useful. When you hit this condition the system will already be 240+ loops in and they will all have to be unwound to get the system back into a usable state.

Adding the code to glass that throws an exception and writing up a manual test case is easy. Writing up an automated test case is much harder (at least for me).

> On Mar 10, 2025, at 7:47?PM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.
> 
> I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
> From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
> And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.
> 
> Best
> Christopher Schnick
> 
> On 10/03/2025 18:51, Andy Goryachev wrote:
>> This looks to me like it might be hitting the (native) thread stack size limit.
>>  
>> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>>  
>>      * An application may enter several nested loops recursively. There's no
>>      * limit of recursion other than that imposed by the native stack size.
>>  
>>  
>> -andy
>>  
>>  
>>  
>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>> Date: Monday, March 10, 2025 at 10:10
>> To: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>> Subject: Re: JVM crashes on macOS when entering too many nested event loops
>> 
>> Hi Christopher,
>> 
>> I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
>> I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.
>> 
>> Martin
>> 
>> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>> > 
>> > Hello,
>> > 
>> > I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>> > 
>> > As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>> > 
>> > Best
>> > Christopher Schnick<hs_err_pid.txt>
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250311/f87d824e/attachment-0001.htm>

From angorya at openjdk.org  Tue Mar 11 19:52:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 11 Mar 2025 19:52:27 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v4]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <4d3woLNvRMJRFW-n1vT3qmUmDOHu8OfSkzmEIOZiYCg=.18f8e02d-d128-4a03-8dd6-1547aac69f98@github.com>

> Additional RichTextArea API tests.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into 8347359.rta.api.tests
 - review comments
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into
   8347359.rta.api.tests
 - newlines
 - check
 - cleanup
 - ... and 12 more: https://git.openjdk.org/jfx/compare/1c3cfcb8...b8e59bd7

-------------

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=03
  Stats: 1383 lines in 10 files changed: 1323 ins; 29 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1677/head:pull/1677

PR: https://git.openjdk.org/jfx/pull/1677

From philip.race at oracle.com  Tue Mar 11 20:01:04 2025
From: philip.race at oracle.com (Philip Race)
Date: Tue, 11 Mar 2025 13:01:04 -0700
Subject: Building OpenJFX with the JDK build system
In-Reply-To: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
References: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
Message-ID: <321bb7c6-ccce-4414-bb6b-3c68d3ed3ec6@oracle.com>

I see no one has responded. That isn't because of a lack of interest .. 
we just haven't had time to discuss it.

Undoubtedly a lot of details to figure out but my take is this is worth 
pursuing.

For webkit, I'd like to think it is *possible* to build it using the JDK 
build system, at least
used as a bootstrap for the cmake webkit build, and at the end to 
collect the artifacts.

A "clean up compiler warnings" effort would be valuable on its own.
Until we actually transitioned the build, we'd probably have to add to 
the gradle system
a way to disable specific warnings, like the JDK does, because it isn't 
practical to eliminate all warnings,
since they some times come from a 3rd party library.

-phil.


On 2/27/25 7:15 AM, Johan Vos wrote:
> Hi,
>
> I introduced this topic during the OpenJDK Committers' workshop in 
> Brussels, on Feb 3, 2025.
> For a long time, I was thinking about building OpenJFX using the JDK 
> buildsystem, and I just blogged about a very basic and limited POC for 
> doing so on Linux: 
> https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/ 
> . The POC I have for this (linux-only at the moment) is at 
> https://github.com/johanvos/jdk/tree/jfxpoc-blog
> This is just a personal idea and effort, but I would be more than 
> happy to discuss how we as the OpenJFX developers might benefit from this.
>
> One of the main reasons for doing this (I list a number of reasons in 
> my blog post), is the cross-compilation capability. It is also very 
> convenient that the result of the build is now a full JDK image, 
> including the JavaFX modules. I am aware that some companies 
> distribute JavaFX modules with their JDK distribution, and this might 
> help a better alignment.
>
> Since I am also the OpenJDK/Mobile project lead, I have to work with 
> the JDK build system anyhow. To me personally, it saves a major amount 
> of time if I only have?to use 1 build system (configure/make) instead 
> of 2 build systems. This is no criticism at all to Gradle, but I lack 
> the expertise (and time to learn) needed to work efficiently with it. 
> With all the projects I do, I try to be as efficient as possible with 
> my time, and streamlining build systems helps.
> The JDK build system is really excellent, and since it is used by so 
> many OpenJDK developers, it feels very familiar. The delta that is 
> needed to have it working and support for JavaFX is very small.
>
> The POC I did is far from complete. There are a number of issues that 
> need to be tackled, e.g.:
> * what about webkit?
> * we have a code-generator for shaders, that is using a very old 
> external dependency. While the JDK build system has great support to 
> generate code, I'm not sure this is the ideal approach
> * warnings, warnings and warnings.
>
> The last item is something that I believe should be tacklked in any 
> case. I had to disable the warnings-as-errors, and I had to add a fair 
> amount of exceptions to javac warnings. This might be a good time to 
> look into this as well.
>
> Again, I want to stress that this is just an experiment I did because 
> it would save me lots of time, and make it much easier for me to 
> understand what is going on in builds. I absolutely do not want to 
> imply that this is much better than what we currently have. But maybe 
> others are interested as well, and in that case we can discuss this.
>
> - Johan


From kcr at openjdk.org  Tue Mar 11 20:23:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 20:23:44 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
Message-ID: <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>

On Tue, 4 Mar 2025 17:35:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md
>
> doc-files/notes/24/JDK-8340852-ScrollPane.md line 7:
> 
>> 5: The fix for [JDK-8340852](https://bugs.openjdk.org/browse/JDK-8340852) changed the behavior of `ScrollPane`. With the latest update, `ScrollPane` only responds to keyboard navigation when it is the focused node. If you prefer the previous behavior, where `ScrollPane` always reacts to arrow keys and other navigational inputs, you can manually restore it by adding an event handler:
>> 6: 
>> 7: ```
> 
> Syntax highlighting:
> Suggestion:

Done.

> doc-files/notes/24/JDK-8340852-ScrollPane.md line 31:
> 
>> 29: ```
>> 30: Using this helper method to convert scroll fractions to values for the scrollbars, and set them:
>> 31: ```
> 
> Suggestion:

Done.

> doc-files/notes/24/JDK-8340852-ScrollPane.md line 54:
> 
>> 52: }
>> 53: ```
>> 54: Adding this event handler will make ScrollPane react to navigation keys as it did before the update.
> 
> Suggestion:
> 
> Adding this event handler will make `ScrollPane` react to navigation keys as it did before the update.

Done.

> doc-files/release-notes-24.md line 70:
> 
>> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
>> 69: 
>> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the IIORegistry class. Refer to the Java Image I/O documentation for more information.
> 
> "Refer to the Java Image I/O documentation for more information."
> 
> Perhaps give a link to the Image I/O documentation?

Done.

> doc-files/release-notes-24.md line 134:
> 
>> 132: [JDK-8343398](https://bugs.openjdk.org/browse/JDK-8343398) | Add reducedData preference | graphics
>> 133: [JDK-8345188](https://bugs.openjdk.org/browse/JDK-8345188) | Support tree-structural pseudo-classes | scenegraph
>> 134: 
> 
> Should we give a link to https://openjfx.io/javadoc/24/new-list.html to easily see new API (when the docs are published)? Maybe even to https://openjfx.io/javadoc/24/deprecated-list.html.

That seems like a reasonable addition. I moved this after the list of enhancements rather than putting it between the two sections.

> doc-files/release-notes-24.md line 191:
> 
>> 189: [JDK-8338701](https://bugs.openjdk.org/browse/JDK-8338701) | Provide media support for libavcodec version 61 | media
>> 190: [JDK-8346228](https://bugs.openjdk.org/browse/JDK-8346228) | Update GStreamer to 1.24.10 | media
>> 191: [JDK-8346229](https://bugs.openjdk.org/browse/JDK-8346229) | Update Glib to 2.82.4 | media
> 
> I'm not sure it's beneficial to include obsolete version updates. If the final update of a dependency is to 1.2.3, then any previous update (1.2.1) doesn't need to be listed, in my opinion.

This is similar (but not quite the same) to the case of a bug that was introduced and fixed in the same release, which we exclude with the rationale that the end user or app developer who updates from one release to the next never sees the interim state. I can see a case for excluding these two third-party updates using the same reasoning.

What do others think? @hjohn @johanvos @andy-goryachev-oracle ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990063059
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990063302
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990063411
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990064085
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990064515
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990068071

From kcr at openjdk.org  Tue Mar 11 20:23:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 20:23:45 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <O74JcJXzQb3k9GGUbu14PHPErKD7sNone0GjxRnfBxg=.0b47fe6d-beae-4168-9cc9-e3cea5714bb4@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <O74JcJXzQb3k9GGUbu14PHPErKD7sNone0GjxRnfBxg=.0b47fe6d-beae-4168-9cc9-e3cea5714bb4@github.com>
Message-ID: <2T0rKs8yhh9gyAJ18kJxJV_0VsQbRHzvYxYJqKvCfpw=.e91988ce-71a3-4263-9d62-c052d6b4af1b@github.com>

On Sat, 1 Mar 2025 10:26:35 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8340852-info.md --> JDK-8340852-ScrollPane.md
>
> doc-files/release-notes-24.md line 66:
> 
>> 64: See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) for more information.
>> 65: 
>> 66: ### Pluggable Image Loading via javax.imageio
> 
> Suggestion:
> 
> ### Pluggable Image Loading via `javax.imageio`

Done.

> doc-files/release-notes-24.md line 70:
> 
>> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
>> 69: 
>> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the IIORegistry class. Refer to the Java Image I/O documentation for more information.
> 
> Suggestion:
> 
> Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the `IIORegistry` class. Refer to the Java Image I/O documentation for more information.

Done.

> doc-files/release-notes-24.md line 74:
> 
>> 72: See [JDK-8306707](https://bugs.openjdk.org/browse/JDK-8306707) for more information.
>> 73: 
>> 74: ### ScrollPane Consumes Navigation Keys Only When It Has Direct Focus
> 
> Suggestion:
> 
> ### `ScrollPane` Consumes Navigation Keys Only When It Has Direct Focus

Done.

> doc-files/release-notes-24.md line 90:
> 
>> 88: Likewise, as of JavaFX 24, it is no longer possible to run JavaFX applications with a security manager enabled. This is true even if you run your application on an older JDK that still supports the security manager.
>> 89: 
>> 90: The following exception will be thrown when the JavaFX runtime is initialized if the Security Manager is enabled:
> 
> I think this would flow better as:
> 
> Suggestion:
> 
> The following exception will be thrown when the JavaFX runtime is initialized with the Security Manager enabled:

Done.

> doc-files/release-notes-24.md line 100:
> 
>> 98: ## Known Issues
>> 99: 
>> 100: ### JavaFX Warning Printed for Use of Terminally Deprecated Methods in sun.misc.Unsafe
> 
> Suggestion:
> 
> ### JavaFX Warning Printed for Use of Terminally Deprecated Methods in `sun.misc.Unsafe`

Done.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990063564
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990063728
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990064176
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990064289
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990064379

From kcr at openjdk.org  Tue Mar 11 20:23:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 20:23:45 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
Message-ID: <LToJrCRTuRbdsMc4ibUFrwW-ThfMc5uUA0gXcg-VOZE=.5fffccba-ddc5-44ef-aeec-9c1266702949@github.com>

On Tue, 11 Mar 2025 20:20:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

doc-files/release-notes-24.md line 70:

> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
> 69: 
> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the `IIORegistry` class. Refer to the Java [Image I/O documentation](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/javax/imageio/package-summary.html) for more information.

NOTE to reviewers: I will change this to 24 with the next commit, but since it will be transiently broken, I wanted to give reviewers a chance to see the page with working links.

doc-files/release-notes-24.md line 154:

> 152: [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418) | [Linux] Replace obsolete XIM as Input Method Editor | window-toolkit
> 153: 
> 154: See the API docs for a list of [new APIs](https://openjfx.io/javadoc/23/new-list.html) and [deprecated APIs](https://openjfx.io/javadoc/23/deprecated-list.html) in each release.

I'll change this from 23 to 24 in the next commit.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990073278
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990073751

From kcr at openjdk.org  Tue Mar 11 20:23:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 20:23:44 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
Message-ID: <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>

> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 24:
> 
> https://bugs.openjdk.org/issues/?filter=46704
> 
> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).

Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1712/files
  - new: https://git.openjdk.org/jfx/pull/1712/files/6f8cb54b..2cabc370

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=02-03

  Stats: 10 lines in 2 files changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jfx/pull/1712.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1712/head:pull/1712

PR: https://git.openjdk.org/jfx/pull/1712

From jhendrikx at openjdk.org  Tue Mar 11 20:24:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 20:24:00 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <zZuZOQjv-KN0FO6zE0d0K6YxZpyVSuheJ8fglZMeBv0=.1464b3ca-c44e-4d0c-af70-d186b5a37d81@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

@mstr2 could you have a look?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2715617650

From kcr at openjdk.org  Tue Mar 11 20:27:04 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 20:27:04 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <LToJrCRTuRbdsMc4ibUFrwW-ThfMc5uUA0gXcg-VOZE=.5fffccba-ddc5-44ef-aeec-9c1266702949@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
 <LToJrCRTuRbdsMc4ibUFrwW-ThfMc5uUA0gXcg-VOZE=.5fffccba-ddc5-44ef-aeec-9c1266702949@github.com>
Message-ID: <n8274yj4vWA38zzgOd40hRyNyrEbXIjx1Uukw9uiLdc=.0fc99511-e2a5-4d4b-aeb2-f510890ddacc@github.com>

On Tue, 11 Mar 2025 20:20:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> doc-files/release-notes-24.md line 70:
> 
>> 68: JavaFX 24 supports the Java Image I/O API, allowing applications to use third-party image loaders in addition to the built-in image loaders. This includes the ability to use variable-density image loaders for formats like SVG. When an image is loaded using a variable-density image loader, JavaFX rasterizes the image with the screen's DPI scaling.
>> 69: 
>> 70: Applications that want to use this feature can use existing open-source Image I/O extension libraries, or register a custom Image I/O service provider instance with the `IIORegistry` class. Refer to the Java [Image I/O documentation](https://docs.oracle.com/en/java/javase/23/docs/api/java.desktop/javax/imageio/package-summary.html) for more information.
> 
> NOTE to reviewers: I will change this to 24 with the next commit, but since it will be transiently broken, I wanted to give reviewers a chance to see the page with working links.

Actually, I'll leave one as "23", since all of our API docs also point to 23 (since that's the boot JDK we use).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990077951

From angorya at openjdk.org  Tue Mar 11 20:27:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 11 Mar 2025 20:27:06 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
 <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
Message-ID: <Yx6-djVWxMlR3YPVTM2S7HrlHPyDdJtm7jbprxOHIsM=.1e88c7eb-81d8-47e3-91a2-62a5b3beed54@github.com>

On Tue, 11 Mar 2025 20:15:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-24.md line 191:
>> 
>>> 189: [JDK-8338701](https://bugs.openjdk.org/browse/JDK-8338701) | Provide media support for libavcodec version 61 | media
>>> 190: [JDK-8346228](https://bugs.openjdk.org/browse/JDK-8346228) | Update GStreamer to 1.24.10 | media
>>> 191: [JDK-8346229](https://bugs.openjdk.org/browse/JDK-8346229) | Update Glib to 2.82.4 | media
>> 
>> I'm not sure it's beneficial to include obsolete version updates. If the final update of a dependency is to 1.2.3, then any previous update (1.2.1) doesn't need to be listed, in my opinion.
>
> This is similar (but not quite the same) to the case of a bug that was introduced and fixed in the same release, which we exclude with the rationale that the end user or app developer who updates from one release to the next never sees the interim state. I can see a case for excluding these two third-party updates using the same reasoning.
> 
> What do others think? @hjohn @johanvos @andy-goryachev-oracle ?

I am in favor of keeping intermediary revisions for the same reason @kevinrushforth mentioned, and also because it eliminates manual filtering (?) and associated mistakes.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990078118

From angorya at openjdk.org  Tue Mar 11 20:40:05 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 11 Mar 2025 20:40:05 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
Message-ID: <vc_Ad6mih_VSBLHSp43c50S1AtK8svknomWL9OVlixQ=.31bad0f9-3790-42b7-9e6d-530e0066928f@github.com>

On Tue, 11 Mar 2025 20:23:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Lgtm

doc-files/release-notes-24.md line 29:

> 27: For example:
> 28: 
> 29: ```

minor: you could use 'console' language identifier for syntax highlighting of command lines, though it does not do much for the code blocks in this file

preview the result here:
https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/Test.md

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2676066777
PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990094344

From jhendrikx at openjdk.org  Tue Mar 11 20:51:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 20:51:58 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
Message-ID: <DKkTLZNljxhG-t_2n_O442svtChJBIn8np9SlCgUmn4=.7c013fd5-5ccf-410b-b1a7-64085885dec2@github.com>

On Tue, 11 Mar 2025 20:23:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

Marked as reviewed by jhendrikx (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2676089671

From jhendrikx at openjdk.org  Tue Mar 11 20:51:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 11 Mar 2025 20:51:58 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <Yx6-djVWxMlR3YPVTM2S7HrlHPyDdJtm7jbprxOHIsM=.1e88c7eb-81d8-47e3-91a2-62a5b3beed54@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
 <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
 <Yx6-djVWxMlR3YPVTM2S7HrlHPyDdJtm7jbprxOHIsM=.1e88c7eb-81d8-47e3-91a2-62a5b3beed54@github.com>
Message-ID: <-t4Eps-I0Ba87rGB7poQcV2zl7oPiQpZWyS7ROY5mOs=.ebbbdccf-5dea-4f9c-af92-3fd864070969@github.com>

On Tue, 11 Mar 2025 20:24:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This is similar (but not quite the same) to the case of a bug that was introduced and fixed in the same release, which we exclude with the rationale that the end user or app developer who updates from one release to the next never sees the interim state. I can see a case for excluding these two third-party updates using the same reasoning.
>> 
>> What do others think? @hjohn @johanvos @andy-goryachev-oracle ?
>
> I am in favor of keeping intermediary revisions for the same reason @kevinrushforth mentioned, and also because it eliminates manual filtering (?) and associated mistakes.

I would say they're not needed.  It could be confusing I suppose (you may at first glance think GStreamer is now version 1.24.6)  On the other hand, I can understand wanting to list all the JDK issues that were involved in a release.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990106526

From kcr at openjdk.org  Tue Mar 11 21:02:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 21:02:02 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <vc_Ad6mih_VSBLHSp43c50S1AtK8svknomWL9OVlixQ=.31bad0f9-3790-42b7-9e6d-530e0066928f@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
 <vc_Ad6mih_VSBLHSp43c50S1AtK8svknomWL9OVlixQ=.31bad0f9-3790-42b7-9e6d-530e0066928f@github.com>
Message-ID: <jdJsVUfimEbU2SUABw4w_X52n9-ZESO_yNHr8qIBzkU=.613e92a5-7c54-43b1-bb8a-f428d9e00a15@github.com>

On Tue, 11 Mar 2025 20:37:19 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> doc-files/release-notes-24.md line 29:
> 
>> 27: For example:
>> 28: 
>> 29: ```
> 
> minor: you could use 'console' language identifier for syntax highlighting of command lines, though it does not do much for the code blocks in this file
> 
> preview the result here:
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Tests/Test.md

Interesting idea, thanks. I think I'll leave this as is, since, as you point out, it doesn't really do much in this particular case.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990119744

From kcr at openjdk.org  Tue Mar 11 21:02:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 11 Mar 2025 21:02:03 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
 <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
Message-ID: <tQwt4Gp1LOldGb3fw2wpfTHyiEEKVaRlSCzjT2NhMjM=.58440df6-13ee-495d-ac9a-742f2c227638@github.com>

On Tue, 11 Mar 2025 20:15:49 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> doc-files/release-notes-24.md line 191:
>> 
>>> 189: [JDK-8338701](https://bugs.openjdk.org/browse/JDK-8338701) | Provide media support for libavcodec version 61 | media
>>> 190: [JDK-8346228](https://bugs.openjdk.org/browse/JDK-8346228) | Update GStreamer to 1.24.10 | media
>>> 191: [JDK-8346229](https://bugs.openjdk.org/browse/JDK-8346229) | Update Glib to 2.82.4 | media
>> 
>> I'm not sure it's beneficial to include obsolete version updates. If the final update of a dependency is to 1.2.3, then any previous update (1.2.1) doesn't need to be listed, in my opinion.
>
> This is similar (but not quite the same) to the case of a bug that was introduced and fixed in the same release, which we exclude with the rationale that the end user or app developer who updates from one release to the next never sees the interim state. I can see a case for excluding these two third-party updates using the same reasoning.
> 
> What do others think? @hjohn @johanvos @andy-goryachev-oracle ?

> I am in favor of keeping intermediary revisions for the same reason @kevinrushforth mentioned, and also because it eliminates manual filtering (?) and associated mistakes.

Actually, I was pointing out that it might be more consistent to _not_ keep them -- treating them like transiently introduced bugs -- but I can see both points. I'll let this percolate for a day or two and then we can decide.

By default I'll leave them in since that's what we've done in the past, but they add little value.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1990118384

From credmond at certak.com  Wed Mar 12 00:18:32 2025
From: credmond at certak.com (Cormac Redmond)
Date: Wed, 12 Mar 2025 00:18:32 +0000
Subject: Probably bug: UI changes made while minimized,
 not reflected upon restore/maximize
Message-ID: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>

Hi all,

A user reported this on reddit:
https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/

I do feel this is a bug so I'm raising it here. Windows 11, JFX 23.0.2.

A quick summary is: if you change a Label while your app is minimized, for
example, the change does not get reflected when restored/maximised, unless
_something else_ triggers a redraw, such as a window resize, or a hover
over a button, etc.

The act of simply maximising the window does seem to trigger a redraw. I
think it should.

Here are two fairly self-explanatory Java classes to demonstrate the
problem (adapted from the reddit post).

Steps:

- Run MinimizeBugApp, observe label
- Run Client, hit enter and observe label change as expected
- Minimize app, and hit enter on Client one or more times (all triggering
label changes)
- Restore app, note Label incorrectly still *displays* the same value as
before the minimize, despite update(s)
- Re-size window to force a redraw, observe correct label value appears


public class MinimizeBugApp extends Application {

    public void start(Stage stage) {
        Label label = new Label("This should be modified when the signal is
received");

        StackPane stackPane = new StackPane();
        stackPane.getChildren().add(label);
        Scene scene = new Scene(stackPane, 500, 500);
        stage.setScene(scene);
        stage.show();

        new Thread(() -> {
            this.startServer(label);
        }).start();
    }

    void startServer(final Label label) {
        try (ServerSocket serverSocket = new ServerSocket(1590)) {
            while (true) {
                System.out.println("Waiting for connection...");
                serverSocket.accept();
                Platform.runLater(() -> {
                    System.out.println("Setting signal is received...");
                    label.setText("The signal is received " + new Date());

                    // This will print the correct text, always -- but the
texted isn't what is reflected if
                    // it's minimized and then maximized
                    System.out.println("Label text should be: " +
label.getText());
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        launch();
    }
}


// Simple test to trigger something in a JavaFX app via a socket
public class Client {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        while (true) {
            try {
                System.out.print("Hit enter to create connection");
                scanner.nextLine();
                new Socket("localhost", 1590);
                System.out.println("Created connection");
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}


Any thoughts? Is this by design for some reason, or a bug?



Kind Regards,

*Cormac Redmond*
Software Engineer, Certak Ltd.

e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/886c0e89/attachment-0001.htm>

From nlisker at openjdk.org  Wed Mar 12 00:38:13 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 00:38:13 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <GFGb4MLBPU1IzI2QlYw0TymOeyfHRwo823anN75pm94=.d6146fd4-b186-4ad6-a8a1-04f532040496@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <8A3yqfHTOdeADGmSEaXCJOCDhqojMVDcq-R1t79r3PA=.ff372cfe-4b3e-4081-84ec-d243d298ce76@github.com>
 <GFGb4MLBPU1IzI2QlYw0TymOeyfHRwo823anN75pm94=.d6146fd4-b186-4ad6-a8a1-04f532040496@github.com>
Message-ID: <mQ2b_PBFNadNE2PcKUUcIyL7TgU8r9lptsivDvxEW3c=.4a7379e3-d0f6-4487-adfa-b149fbbf16bc@github.com>

On Tue, 11 Mar 2025 06:34:06 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I'm unsure what you are saying here. The common divisor example would not log a warning if I place the warning log in the same location as the SOE.

If you replace the thrown error/exception with logging then the code path will continue. What behavior will we get instead? The one before the modification where "first listener wins"?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2716060500

From nlisker at openjdk.org  Wed Mar 12 00:38:13 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 00:38:13 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
Message-ID: <7LWrxjamBVglfLrqkCaOIi-7nuQESCUN4cwDthBfYXA=.1cb9dbf6-b4b5-43d3-a41d-fd0215e3578a@github.com>

On Sun, 9 Mar 2025 23:05:02 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix non-convergence logic one more time...
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 168:
> 
>> 166:      *   can be {@code null} which means there are no listeners to notify
>> 167:      */
>> 168:     public void fireValueChanged(I instance, Object listenerData) {
> 
> Same comments. `null` check on `instance`?

Is a switch expression on `listenerData` not suitable here?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990350890

From jhendrikx at openjdk.org  Wed Mar 12 01:25:04 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 01:25:04 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v12]
In-Reply-To: <mQ2b_PBFNadNE2PcKUUcIyL7TgU8r9lptsivDvxEW3c=.4a7379e3-d0f6-4487-adfa-b149fbbf16bc@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <9yqfvlpSqYKG8OvG2OzEhGy0RaphU6MlGQK8SYWdET0=.1132b77d-a12f-4ec2-b4ce-0db5be288cbf@github.com>
 <8A3yqfHTOdeADGmSEaXCJOCDhqojMVDcq-R1t79r3PA=.ff372cfe-4b3e-4081-84ec-d243d298ce76@github.com>
 <GFGb4MLBPU1IzI2QlYw0TymOeyfHRwo823anN75pm94=.d6146fd4-b186-4ad6-a8a1-04f532040496@github.com>
 <mQ2b_PBFNadNE2PcKUUcIyL7TgU8r9lptsivDvxEW3c=.4a7379e3-d0f6-4487-adfa-b149fbbf16bc@github.com>
Message-ID: <LvUXYzdCKirGI1FqLELuOViNnXoNnEm8w9hbwOIxy_I=.b82675c0-2c9c-4b31-9ec4-107082c672f3@github.com>

On Wed, 12 Mar 2025 00:33:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> > I'm unsure what you are saying here. The common divisor example would not log a warning if I place the warning log in the same location as the SOE.
> 
> If you replace the thrown error/exception with logging then the code path will continue. What behavior will we get instead? The one before the modification where "first listener wins"?

Yeah, if there's disagreement, then the listener earliest in the chain (if it is persistent) will win, and one of the disagreeing listeners (after setting a value) will not have been notified of that change (as it was changed back).  Note that there's no inconsistency here; after all notification loops complete, the last received new value will match the current value of the property.  This goes for **all** listeners, regardless of disagreements.  In other words:

         (obs, ov, nv) - {
               // new value received here is ALWAYS going to be correct after the full notification completes

               // There is no guarantee that after calling set(X) that the value actually will become X (there
               // never was such a guarantee, also not with ExpressionHelper as other listeners can interfere
               // at any time).  So if you didn't receive a new value X, it hasn't actually become X.
               property.set(X);  
               
               // Calling this afterwards could allow you to see that your change was "rejected"
               if (property.get()  != X) {}
         }
         
Realistically, there's not really that much wrong with this.  It is just that listeners should not make assumptions that a value passed to `property.set` will become the final state.  The only way to be sure is to have received a call back with that value as the new 
value.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1081#issuecomment-2716132609

From nlisker at openjdk.org  Wed Mar 12 01:32:10 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 01:32:10 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
Message-ID: <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>

On Tue, 11 Mar 2025 06:45:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
>> 
>> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
>> 
>> # Behavior
>> 
>> |Listener...|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
>> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
>> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
>> 
>> ## Nested notifications:
>> 
>> | |ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Type|Depth first (call stack increases for each nested level)|(same)|
>> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
>> |Vetoing Possible?|No|Yes|
>> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
>> 
>> # Performance
>> 
>> |Listener|ExpressionHelper|ListenerManager|
>> |---|---|---|
>> |Addition|Array based, append in empty slot, resize as needed|(same)|
>> |Removal|Array based, shift array, resize as needed|(same)|
>> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
>> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
>> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
>> |Notifying Invalidation Listeners|1 ns each|(same)|
>> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
>> 
>> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
>> 
>> # Memory Use 
>> 
>> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
>> 
>> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
>> |---|---|---|---|
>> |No Listeners|none|none|none|
>> |Single InvalidationListener|16 bytes overhead|none|none|
>> |Single ChangeListener|20 bytes overhead|none|16 bytes overhe...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break up long lines of code

Finished the 2nd part of the implementation review. I didn't delve into the logic of the listener management, but it looks sane :)

I'll review the tests as the final part.

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 96:

> 94: 
> 95:     private static final ArrayManager<ListenerListBase, InvalidationListener> INVALIDATION_LISTENERS = new CompactingArrayManager<>(InvalidationListener.class) {
> 96:         @Override

Empty line

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 118:

> 116: 
> 117:     private static final ArrayManager<ListenerListBase, Object> CHANGE_LISTENERS = new CompactingArrayManager<>(Object.class) {
> 118:         @Override

Empty line

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 193:

> 191:         else {
> 192:             CHANGE_LISTENERS.add(this, listener1);
> 193:         }

These can be

switch (listener1) {
    case InvalidationListener il -> INVALIDATION_LISTENERS.add(this, il);
    default -> CHANGE_LISTENERS.add(this, listener1);
}

but I don't know if it helps.

modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 422:

> 420: 
> 421:     private void assertInvalidationListenerIndex(int index) {
> 422:         assert index < invalidationListenersCount : index + " >= " + invalidationListenersCount + ", results would be undefined";

Do we allow `assert` in production code? This will require to run the application with `ea`. Or are these intended to be skipped in production and are for tests only?

modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java line 109:

> 107:     public void addListener(ChangeListener<? super T> listener) {
> 108:         observed = observed || listener != null;
> 109:         LISTENER_MANAGER.addListener(this, (ChangeListener<Object>) listener);

This cast gives a warning.

modules/javafx.base/src/main/java/javafx/beans/property/ObjectPropertyBase.java line 101:

> 99:     @Override
> 100:     public void addListener(ChangeListener<? super T> listener) {
> 101:         LISTENER_MANAGER.addListener(this, (ChangeListener<Object>) listener);

This cast gives a warning.

modules/javafx.base/src/main/java/javafx/beans/property/ReadOnlyObjectPropertyBase.java line 76:

> 74:     @Override
> 75:     public void addListener(ChangeListener<? super T> listener) {
> 76:         LISTENER_MANAGER.addListener(this, (ChangeListener<Object>) listener);

Warning

modules/javafx.base/src/main/java/javafx/beans/value/ObservableValueBase.java line 78:

> 76:     @Override
> 77:     public void addListener(ChangeListener<? super T> listener) {
> 78:         LISTENER_MANAGER.addListener(this, (ChangeListener<Object>) listener);

Warning

-------------

PR Review: https://git.openjdk.org/jfx/pull/1081#pullrequestreview-2676530002
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990363868
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990363984
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990366337
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990370006
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990385681
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990385008
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990386512
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990387231

From jhendrikx at openjdk.org  Wed Mar 12 01:32:11 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 01:32:11 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <7LWrxjamBVglfLrqkCaOIi-7nuQESCUN4cwDthBfYXA=.1cb9dbf6-b4b5-43d3-a41d-fd0215e3578a@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <7LWrxjamBVglfLrqkCaOIi-7nuQESCUN4cwDthBfYXA=.1cb9dbf6-b4b5-43d3-a41d-fd0215e3578a@github.com>
Message-ID: <RkmrXrDqsCXJV0_Its9vnFOepSxgViScQewiWG2u8dQ=.c2521589-4c82-4a11-9ae6-479840a3f224@github.com>

On Wed, 12 Mar 2025 00:35:10 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/OldValueCachingListenerManager.java line 168:
>> 
>>> 166:      *   can be {@code null} which means there are no listeners to notify
>>> 167:      */
>>> 168:     public void fireValueChanged(I instance, Object listenerData) {
>> 
>> Same comments. `null` check on `instance`?
>
> Is a switch expression on `listenerData` not suitable here?

This is a really hot code path, and the current version came out best in the benchmarks. I didn't try modify this one for that reason.  I did try for the `removeListener` code (as performance is irrelevant there), but it was a poor fit for `switch` (duplicate cases, duplicate code, and can't do fall through or multiple options with `when` expressions it seems...)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990388631

From credmond at certak.com  Wed Mar 12 01:36:09 2025
From: credmond at certak.com (Cormac Redmond)
Date: Wed, 12 Mar 2025 01:36:09 +0000
Subject: Probably bug: UI changes made while minimized,
 not reflected upon restore/maximize
In-Reply-To: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
References: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
Message-ID: <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>

That meant to say: the act of simply maximising the window ***doesn't***
seem to trigger a redraw.


On Wed, 12 Mar 2025 at 00:19, Cormac Redmond <credmond at certak.com> wrote:

> Hi all,
>
> A user reported this on reddit:
> https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/
>
> I do feel this is a bug so I'm raising it here. Windows 11, JFX 23.0.2.
>
> A quick summary is: if you change a Label while your app is minimized, for
> example, the change does not get reflected when restored/maximised, unless
> _something else_ triggers a redraw, such as a window resize, or a hover
> over a button, etc.
>
> The act of simply maximising the window does seem to trigger a redraw. I
> think it should.
>
> Here are two fairly self-explanatory Java classes to demonstrate the
> problem (adapted from the reddit post).
>
> Steps:
>
> - Run MinimizeBugApp, observe label
> - Run Client, hit enter and observe label change as expected
> - Minimize app, and hit enter on Client one or more times (all triggering
> label changes)
> - Restore app, note Label incorrectly still *displays* the same value as
> before the minimize, despite update(s)
> - Re-size window to force a redraw, observe correct label value appears
>
>
> public class MinimizeBugApp extends Application {
>
>     public void start(Stage stage) {
>         Label label = new Label("This should be modified when the signal
> is received");
>
>         StackPane stackPane = new StackPane();
>         stackPane.getChildren().add(label);
>         Scene scene = new Scene(stackPane, 500, 500);
>         stage.setScene(scene);
>         stage.show();
>
>         new Thread(() -> {
>             this.startServer(label);
>         }).start();
>     }
>
>     void startServer(final Label label) {
>         try (ServerSocket serverSocket = new ServerSocket(1590)) {
>             while (true) {
>                 System.out.println("Waiting for connection...");
>                 serverSocket.accept();
>                 Platform.runLater(() -> {
>                     System.out.println("Setting signal is received...");
>                     label.setText("The signal is received " + new Date());
>
>                     // This will print the correct text, always -- but the
> texted isn't what is reflected if
>                     // it's minimized and then maximized
>                     System.out.println("Label text should be: " +
> label.getText());
>                 });
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
>
>     public static void main(String[] args) {
>         launch();
>     }
> }
>
>
> // Simple test to trigger something in a JavaFX app via a socket
> public class Client {
>     public static void main(String[] args) {
>         Scanner scanner = new Scanner(System.in);
>
>         while (true) {
>             try {
>                 System.out.print("Hit enter to create connection");
>                 scanner.nextLine();
>                 new Socket("localhost", 1590);
>                 System.out.println("Created connection");
>             } catch (IOException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
>
>
> Any thoughts? Is this by design for some reason, or a bug?
>
>
>
> Kind Regards,
>
> *Cormac Redmond*
> Software Engineer, Certak Ltd.
>
> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/86d3148e/attachment.htm>

From nlisker at openjdk.org  Wed Mar 12 01:38:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 01:38:01 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <RkmrXrDqsCXJV0_Its9vnFOepSxgViScQewiWG2u8dQ=.c2521589-4c82-4a11-9ae6-479840a3f224@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <7LWrxjamBVglfLrqkCaOIi-7nuQESCUN4cwDthBfYXA=.1cb9dbf6-b4b5-43d3-a41d-fd0215e3578a@github.com>
 <RkmrXrDqsCXJV0_Its9vnFOepSxgViScQewiWG2u8dQ=.c2521589-4c82-4a11-9ae6-479840a3f224@github.com>
Message-ID: <O2YgX2V54JYpxH8QoWBq6tTqgT5OxzbpKFzUUTiRtBY=.4043e9ba-22ce-4bab-9d41-5fec700f9093@github.com>

On Wed, 12 Mar 2025 01:29:26 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Is a switch expression on `listenerData` not suitable here?
>
> This is a really hot code path, and the current version came out best in the benchmarks. I didn't try modify this one for that reason.  I did try for the `removeListener` code (as performance is irrelevant there), but it was a poor fit for `switch` (duplicate cases, duplicate code, and can't do fall through or multiple options with `when` expressions it seems...)

If the benchmarks deem this a better implementation then it's fine. I was just wondering if it was missed.

The `removeListener` one is indeed not as appetizing.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990392759

From jhendrikx at openjdk.org  Wed Mar 12 01:45:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 01:45:06 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
 <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
Message-ID: <qAeFfWLnsktSUeuHmU1U8JVIyi4X67gselHx1XA52Ig=.7a9a0856-414a-446f-b8a2-11320b9bb68a@github.com>

On Wed, 12 Mar 2025 00:55:26 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Break up long lines of code
>
> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 193:
> 
>> 191:         else {
>> 192:             CHANGE_LISTENERS.add(this, listener1);
>> 193:         }
> 
> These can be
> 
> switch (listener1) {
>     case InvalidationListener il -> INVALIDATION_LISTENERS.add(this, il);
>     default -> CHANGE_LISTENERS.add(this, listener1);
> }
> 
> but I don't know if it helps.

I may change my mind later when switch expressions have become a bit more common, but currently I think the if/else version is more readable.

> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 422:
> 
>> 420: 
>> 421:     private void assertInvalidationListenerIndex(int index) {
>> 422:         assert index < invalidationListenersCount : index + " >= " + invalidationListenersCount + ", results would be undefined";
> 
> Do we allow `assert` in production code? This will require to run the application with `ea`. Or are these intended to be skipped in production and are for tests only?

They're useful during testing (when `-ea` is passed, which it generally is). They will help catch bugs if this code is ever refactored.  As for the current implementation, I'm confident that it will never trip these asserts.  It also serves as a bit of documentation.  I'm fine with removing these -- I placed them in separate methods to not mess up inlining of compiled code (asserts will count against the method length limit if placed directly in the method).  As it is now, they will be completely eliminated when not running with `-ea`.

As far as allowing goes -- FX is full of asserts already, so I guess its allowed?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990396334
PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990396289

From nlisker at openjdk.org  Wed Mar 12 01:45:07 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 01:45:07 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v11]
In-Reply-To: <0Zim-ODL6AjzCW3Ro9Oi0SCC7PfBxBE3LIf6gcPdhKY=.b58ecaa3-fd4d-4d5c-bf27-bf22dd432307@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <QLFhTN08qSHt4jw9gu2KWJYyjJ-Aw8XJBfhzTxGnb7k=.7956c786-b761-42e6-810f-29fc3e2ae8c0@github.com>
 <PsFf7i-z7x3lMbnhjmAq0B2hlV4_EpyMRXSsjtjvgeM=.a5f5c927-80a5-49ab-8c05-348b328896fe@github.com>
 <XGLu7DaV7i_X_N3UIJL-7BomTubF3BEoC9J5AQ41Zn0=.edb57bfc-c74c-41c8-be55-3c95b61c52eb@github.com>
 <SD1bst8LgeiXJuxhZ18501TjAckGnbSX8D7js--E8ak=.9da69d2c-dee4-497f-8b94-f1dc16e22c18@github.com>
 <0Zim-ODL6AjzCW3Ro9Oi0SCC7PfBxBE3LIf6gcPdhKY=.b58ecaa3-fd4d-4d5c-bf27-bf22dd432307@github.com>
Message-ID: <Oz7jRfarX1BiXj8cJsm5TKjY17Sp_NFgxdc-th83Vqg=.dd42e02b-474f-4f69-902c-b0c4a1a5dce5@github.com>

On Tue, 11 Mar 2025 07:09:48 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> I think the docs (in `OldValueCachingListenerManager`) are quite clear already though why you'd use one or the other.

Alright, no need to add a note about where it's used.

> The design flaw is the use of a protected `fireValueChangedEvent` method within the property...

The "old value for properties" is interesting, but another discussion. Might be worth bringing it up on the list if there's more to it than just this extra implementation.

> You should never do all three of these for protected methods...

Yes, well, same for public and package methods. This falls under "design for inheritance or prevent it" - don't rely on an implementation that can be overridden.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990397708

From nlisker at openjdk.org  Wed Mar 12 01:49:02 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 01:49:02 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v5]
In-Reply-To: <n1QZmGMveXFVFgPOHFC10Yjx4E3cWzVXGENoa3C5djs=.3d30106a-13ab-48d6-ab53-71b0cd92caf3@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <a8QcT2WNcZbz4lLGkcAufiuuYRtV0hKlq9oTYLfhb3Y=.7213b233-b77b-4864-ad32-8d4021e886f6@github.com>
 <aPPRQ2FqFs7LmjzvlBG7ifovyv2Kl_h2sEvfAWRIdCw=.6c8089f3-bd9d-4150-8223-fd05032732a9@github.com>
 <n1QZmGMveXFVFgPOHFC10Yjx4E3cWzVXGENoa3C5djs=.3d30106a-13ab-48d6-ab53-71b0cd92caf3@github.com>
Message-ID: <2sjc6vD9nWVZr9q936mC8yUUQ1ZK0fT2VFUyOFOejUU=.0fa3d094-211a-4325-887f-5d4d9fcc366b@github.com>

On Fri, 21 Feb 2025 21:42:03 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerManagerBase.java line 41:
>> 
>>> 39:  * @param <I> the type of the instance providing listener data
>>> 40:  */
>>> 41: public abstract class ListenerManagerBase<T, I extends ObservableValue<? extends T>> {
>> 
>> Is this a class and not an interface because of the need for `protected` methods?
>
> I think I extracted this when I discovered that I needed two implementations (caching one and one that doesn't need caching, to save more memory).
> 
> Looking at it now (over a year later) I suppose it could also be an interface.  There is no risk that any of this gets exposed as the property classes will all create a private class to implement the abstract methods.
> 
> It can be changed at any time as it is internal.  If we want to make it an interface, I'm going to need to think of a good name for it (`ListenerDataProvider`, `ListenerDataStore`, ... )

Just making sure you didn't forget to consider this. Fine to leave as is also.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990401323

From nlisker at openjdk.org  Wed Mar 12 01:55:01 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Wed, 12 Mar 2025 01:55:01 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <qAeFfWLnsktSUeuHmU1U8JVIyi4X67gselHx1XA52Ig=.7a9a0856-414a-446f-b8a2-11320b9bb68a@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
 <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
 <qAeFfWLnsktSUeuHmU1U8JVIyi4X67gselHx1XA52Ig=.7a9a0856-414a-446f-b8a2-11320b9bb68a@github.com>
Message-ID: <Y9_M3JxDRwwxLTZ6zJ--gmRwnUDPTk2G_eyRM4VG8MU=.e1bd50c6-3cce-4331-accf-d7cdd7c6cb09@github.com>

On Wed, 12 Mar 2025 01:40:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.base/src/main/java/com/sun/javafx/binding/ListenerListBase.java line 422:
>> 
>>> 420: 
>>> 421:     private void assertInvalidationListenerIndex(int index) {
>>> 422:         assert index < invalidationListenersCount : index + " >= " + invalidationListenersCount + ", results would be undefined";
>> 
>> Do we allow `assert` in production code? This will require to run the application with `ea`. Or are these intended to be skipped in production and are for tests only?
>
> They're useful during testing (when `-ea` is passed, which it generally is). They will help catch bugs if this code is ever refactored.  As for the current implementation, I'm confident that it will never trip these asserts.  It also serves as a bit of documentation.  I'm fine with removing these -- I placed them in separate methods to not mess up inlining of compiled code (asserts will count against the method length limit if placed directly in the method).  As it is now, they will be completely eliminated when not running with `-ea`.
> 
> As far as allowing goes -- FX is full of asserts already, so I guess its allowed?

I don't mind personally, I just know some people "frown upon" `assert` in production code. @kevinrushforth can comment on it, but I don't foresee a problem.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990409315

From jhendrikx at openjdk.org  Wed Mar 12 02:16:12 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 02:16:12 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v13]
In-Reply-To: <Y9_M3JxDRwwxLTZ6zJ--gmRwnUDPTk2G_eyRM4VG8MU=.e1bd50c6-3cce-4331-accf-d7cdd7c6cb09@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <B_QicPaLs3-BiVY-rh2CYNaxYYHkCu6DwqImAoVfTrw=.dfbe3102-abac-4487-82fa-54669a233eb1@github.com>
 <CLRC90wDC33g9sANQkuP8FB3_kUB1dVZ6je3biNQA2I=.faa83b4c-9873-4fa5-873e-dc4e96ed7295@github.com>
 <qAeFfWLnsktSUeuHmU1U8JVIyi4X67gselHx1XA52Ig=.7a9a0856-414a-446f-b8a2-11320b9bb68a@github.com>
 <Y9_M3JxDRwwxLTZ6zJ--gmRwnUDPTk2G_eyRM4VG8MU=.e1bd50c6-3cce-4331-accf-d7cdd7c6cb09@github.com>
Message-ID: <Qjanlhogvgv6fEPPQ-y2qDuGPduB5Vj7IhK4vwZfnGY=.5a246620-99a4-404e-8d5e-f9b199d484d1@github.com>

On Wed, 12 Mar 2025 01:52:16 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> They're useful during testing (when `-ea` is passed, which it generally is). They will help catch bugs if this code is ever refactored.  As for the current implementation, I'm confident that it will never trip these asserts.  It also serves as a bit of documentation.  I'm fine with removing these -- I placed them in separate methods to not mess up inlining of compiled code (asserts will count against the method length limit if placed directly in the method).  As it is now, they will be completely eliminated when not running with `-ea`.
>> 
>> As far as allowing goes -- FX is full of asserts already, so I guess its allowed?
>
> I don't mind personally, I just know some people "frown upon" `assert` in production code. @kevinrushforth can comment on it, but I don't foresee a problem.

I think I left these in because of the need to subclass these, and the subclasses are expected to work in a certain way and must be highly optimized.  Normally, I'd just make them hard checks (with `IllegalStateException` or `IllegalArgumentException`), but for optimal performance it is better to do it with asserts in this case (I don't want it to be too much slower than `ExpressionHelper`).  With the asserts, if you write any kind of test code for your subclasses, then it will fail quickly if you made a mistake.  As said, I'm confident these subclasses that we have now are implemented correctly, but who knows, in the future we may want to use similar code for ListChangeListeners or something...

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990423826

From jhendrikx at openjdk.org  Wed Mar 12 02:27:54 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 02:27:54 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v14]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <D9J_caXVi8oYeBLysCijNxuOeqsWC-j7N_Ynx6k4iNE=.080b61f3-6e5f-47ad-b203-0b85262cd588@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener...

John Hendrikx has updated the pull request incrementally with three additional commits since the last revision:

 - Add final to public methods of ArrayManager
 - Remove duplicate code
 - Doc fixes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/b0263704..7755dc51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=13
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=12-13

  Stats: 27 lines in 3 files changed: 7 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From jhendrikx at openjdk.org  Wed Mar 12 02:27:55 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 02:27:55 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v5]
In-Reply-To: <2sjc6vD9nWVZr9q936mC8yUUQ1ZK0fT2VFUyOFOejUU=.0fa3d094-211a-4325-887f-5d4d9fcc366b@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
 <a8QcT2WNcZbz4lLGkcAufiuuYRtV0hKlq9oTYLfhb3Y=.7213b233-b77b-4864-ad32-8d4021e886f6@github.com>
 <aPPRQ2FqFs7LmjzvlBG7ifovyv2Kl_h2sEvfAWRIdCw=.6c8089f3-bd9d-4150-8223-fd05032732a9@github.com>
 <n1QZmGMveXFVFgPOHFC10Yjx4E3cWzVXGENoa3C5djs=.3d30106a-13ab-48d6-ab53-71b0cd92caf3@github.com>
 <2sjc6vD9nWVZr9q936mC8yUUQ1ZK0fT2VFUyOFOejUU=.0fa3d094-211a-4325-887f-5d4d9fcc366b@github.com>
Message-ID: <YpLrcgumDwT7NLjzqgaysrdtbJcbYf5ECNSaUfHZDkk=.4e61acb8-d319-4082-aae0-2edff2ccd0de@github.com>

On Wed, 12 Mar 2025 01:46:17 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> I think I extracted this when I discovered that I needed two implementations (caching one and one that doesn't need caching, to save more memory).
>> 
>> Looking at it now (over a year later) I suppose it could also be an interface.  There is no risk that any of this gets exposed as the property classes will all create a private class to implement the abstract methods.
>> 
>> It can be changed at any time as it is internal.  If we want to make it an interface, I'm going to need to think of a good name for it (`ListenerDataProvider`, `ListenerDataStore`, ... )
>
> Just making sure you didn't forget to consider this. Fine to leave as is also.

I'll leave it if you don't mind, as said, we're not locked in for now.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1081#discussion_r1990431576

From mstrauss at openjdk.org  Wed Mar 12 06:27:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 12 Mar 2025 06:27:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v51]
In-Reply-To: <Sw9ZdYC4lYigAAQkg_SNZybuEZ18zzsEdGfiFKAWmUg=.1920eae2-f390-4c6e-8639-ad828913101c@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <5kF_rF8l9wEzaf2nbFt7FoK-Xy9JhHUt6E8FF_UmNd8=.90dc3c31-a02d-4bf2-9cc8-582dab59c703@github.com>
 <Sw9ZdYC4lYigAAQkg_SNZybuEZ18zzsEdGfiFKAWmUg=.1920eae2-f390-4c6e-8639-ad828913101c@github.com>
Message-ID: <06ZyAbIduLnjs8z5V9yXXV4QoQxfxtKbBcLbndpk5Ns=.0b1c7bab-a665-467a-81ff-7e9ea758aa5c@github.com>

On Mon, 10 Mar 2025 18:46:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Also on Windows, when the button do appear, their size seems to differ from the native:

I've counted the pixels for different scaling factors, and the sizes of the glyphs are generally within 1px of each other (native vs. JFX). What seems to be happening is a combination of pixel snapping, and a different rasterizer (in this specific case, JFX seems to bias the inner edge, whereas Windows seems to bias the outer edge).

(top is JFX, bottom is native)
<img src="https://github.com/user-attachments/assets/2d838e2f-c5b3-4df4-919b-3ec5cd767446" width=400/>

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2716677645

From mstrauss at openjdk.org  Wed Mar 12 08:05:52 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 12 Mar 2025 08:05:52 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v53]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <wR7Rx5DejY4sdi-eAIMv8oAaRB2URgTkdBDztGT-jGI=.bbd296f3-02a9-45e4-a1e3-3e6896c67de8@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  tweak header button glyph scaling

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/e6e81001..df90ca13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=52
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=51-52

  Stats: 126 lines in 3 files changed: 115 ins; 9 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From crschnick at xpipe.io  Wed Mar 12 08:15:53 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 12 Mar 2025 09:15:53 +0100
Subject: JVM crashes on macOS when entering too many nested event loops
In-Reply-To: <C82AA745-0359-42A6-96B2-962714E94C99@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <85df75dc-13cd-4369-b051-6e3ed05863e1@xpipe.io>
 <C82AA745-0359-42A6-96B2-962714E94C99@gmail.com>
Message-ID: <8c19c7d4-bb34-45dd-9cb7-cb5beb692a79@xpipe.io>

Thank you for your effort on that investigation. Hopefully this issue 
can be fixed somehow. For now, we tweaked some calls to runLater and 
enterNestedEventLoop to be called a little bit less often.

On 11/03/2025 20:40, Martin Fox wrote:
> I entered a bug https://bugs.openjdk.org/browse/JDK-8351733.
>
> This crash doesn?t happen if you create nested event loops while 
> processing events. I wrote a test app that started a new event loop on 
> every mouse click and easily created over 400 nested loops. So we?re 
> not pushing up against the native thread stack size limit, we?re 
> running into an undocumented limit on the number of nested 
> CFRunLoopRun calls. There?s a line to that effect in the crash log 
> (which I overlooked for a while because I?m not used to crash logs 
> being that helpful).
>
> The bug is specific to the way the Mac handles runLater blocks and 
> other internal uses of performSelectorOnMainThread. So far I can only 
> reproduce this using Platform::runLater e.g. block A schedules 
> runLater block B and then enters a nested event loop, block B 
> schedules runLater block C and enters a nested event loop, and on and 
> on. In a real app it?s also possible that some internal uses of 
> performSelectorOnMainThread might be interacting with 
> Platform::runLater calls in unexpected ways.
>
> As far as I know here?s no way to ask the system what the CFRunLoopRun 
> nesting limit is and no way to detect at runtime when we?ve hit it. 
> The best we can do is maintain an internal counter and throw a runtime 
> exception when it hits, say, 245 nested CFRunLoopRun calls. That at 
> least would produce a very long but usable Java stack trace.
>
> I could update Platform::canStartNestedEventLoop?to detect this case 
> but I?m not sure it would be useful. When you hit this condition the 
> system will already be 240+ loops in and they will all have to be 
> unwound to get the system back into a usable state.
>
> Adding the code to glass that throws an exception and writing up a 
> manual test case is easy. Writing up an automated test case is much 
> harder (at least for me).
>
>> On Mar 10, 2025, at 7:47?PM, Christopher Schnick <crschnick at xpipe.io> 
>> wrote:
>>
>> Our code and some libraries do enter some nested event loops at a few 
>> places when it makes sense, but we didn't do anything to explicitly 
>> provoke this, this occurred naturally in our application. So it would 
>> be nice if JavaFX could somehow guard against this, especially since 
>> crashing the JVM is probably the worst thing that can happen.
>>
>> I looked at the documentation, but it seems like the public API at 
>> Platform::enterNestedEventLoop does not mention this.
>> From my understanding, the method Platform::canStartNestedEventLoop 
>> is potentially the right method to indicate to the caller that the 
>> limit is close by returning false.
>> And even if something like an exception is thrown when a nested event 
>> loop is started while it is close to the limit, that would still be 
>> much better than a direct crash.
>>
>> Best
>> Christopher Schnick
>>
>> On 10/03/2025 18:51, Andy Goryachev wrote:
>>> This looks to me like it might be hitting the (native) thread stack 
>>> size limit.
>>> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>>> * An application may enter several nested loops recursively. There's no
>>> * limit of recursion other than that imposed by the native stack size.
>>> -andy
>>>
>>> *From:*openjfx-dev<openjfx-dev-retn at openjdk.org>on behalf of Martin 
>>> Fox<martinfox656 at gmail.com>
>>> *Date:*Monday, March 10, 2025 at 10:10
>>> *To:*Christopher Schnick<crschnick at xpipe.io>
>>> *Cc:*OpenJFX<openjfx-dev at openjdk.org>
>>> *Subject:*Re: JVM crashes on macOS when entering too many nested 
>>> event loops
>>>
>>> Hi Christopher,
>>>
>>> I was able to reproduce this crash. I wrote a small routine that 
>>> recursively calls itself in a runLater block and then enters a 
>>> nested event loop. The program crashes when creating loop 254. I?m 
>>> not sure where that limit comes from so it?s possible that consuming 
>>> some other system resource could lower it. I couldn?t see any good 
>>> way to determine how many loops are active by looking at the crash 
>>> report since it doesn?t show the entire call stack.
>>> I did a quick trial on Linux and was able to create a lot more loops 
>>> (over 600) but then started seeing erratic behavior and errors 
>>> coming from the Java VM. The behavior was variable unlike on the Mac 
>>> which always crashes when creating loop 254.
>>>
>>> Martin
>>>
>>> > On Mar 7, 2025, at 6:24?AM, Christopher 
>>> Schnick<crschnick at xpipe.io>wrote:
>>> >
>>> > Hello,
>>> >
>>> > I have attached a JVM fatal error log that seemingly was caused by 
>>> our JavaFX application entering too many nested event loops, which 
>>> macOS apparently doesn't like.
>>> >
>>> > As far as I know, there is no upper limit defined on how often an 
>>> event loop can be nested, so I think this is a bug that can occur in 
>>> rare situations.
>>> >
>>> > Best
>>> > Christopher Schnick<hs_err_pid.txt>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/67c08e4b/attachment-0001.htm>

From jhendrikx at openjdk.org  Wed Mar 12 10:07:59 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 10:07:59 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v15]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <dDwxDWl8fTgdMrpZuv8g1Q9Ntch6l_z3mkpzgekbLzg=.588c56cd-af5e-4ad5-bd50-f9d59d6781c6@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener...

John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:

 - Formatting
 - Suppress warnings on some unchecked casts

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/7755dc51..10af6ace

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=14
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=13-14

  Stats: 19 lines in 5 files changed: 15 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From kcr at openjdk.org  Wed Mar 12 13:34:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 12 Mar 2025 13:34:10 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v3]
In-Reply-To: <QPXmSEUzZvGAYiSXG9EAUBviG_AIeHFmuHhJ5cKAjtU=.120d7264-cf75-46f1-814b-901470eaa867@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <QPXmSEUzZvGAYiSXG9EAUBviG_AIeHFmuHhJ5cKAjtU=.120d7264-cf75-46f1-814b-901470eaa867@github.com>
Message-ID: <z_mmS863JDJH-rk_wBcbA6wq-3DUSe6Yc3oz2IyCPU8=.072d2f24-65be-4ffe-bf69-65fdf43b23ef@github.com>

On Fri, 7 Feb 2025 09:16:54 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - javadoc
>  - remove supporting documentation
>  - warning can't be suppressed
>  - initialize PreviewFeature early

Looks good. I tested it and it does what I expected. I did some testing with the JDK and I was wrong about one thing:

> I don't think the warning should be suppressible; the equivalent JDK warning isn't

The key difference between the JDK and JavaFX is that the JDK only produces warnings (which are not suppressible) at compile time. Because of the compiler and JVM support, they didn't feel the need for a runtime warning.

Given that ours is a runtime warning, it might be worth restoring the system property to allow the warnings to be suppressed at runtime (default is false). What do you think?

Regarding compile time warnings for deprecated API: Should we specify that the `@Deprecated` annotation on preview features be marked as `forRemoval=true`? I can see arguments for both choices.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2678498489

From duke at openjdk.org  Wed Mar 12 14:00:15 2025
From: duke at openjdk.org (Abhinay Agarwal)
Date: Wed, 12 Mar 2025 14:00:15 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
Message-ID: <cM2YDTcWhz-Asg6GzhBd6_J0sTDRvpT_Oc3ZQdwC25Q=.786d4c89-304e-47eb-9cd3-ce60e06338b8@github.com>

On Tue, 11 Mar 2025 20:23:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

doc-files/release-notes-24.md line 50:

> 48: ```
> 49: 
> 50: NOTE: The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead.

Should the `NOTE` be changed to use Github supported [highlight using blockquote](https://github.com/orgs/community/discussions/16925):


> [!NOTE]
> The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1991561721

From angorya at openjdk.org  Wed Mar 12 14:27:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 12 Mar 2025 14:27:12 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v3]
In-Reply-To: <z_mmS863JDJH-rk_wBcbA6wq-3DUSe6Yc3oz2IyCPU8=.072d2f24-65be-4ffe-bf69-65fdf43b23ef@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <QPXmSEUzZvGAYiSXG9EAUBviG_AIeHFmuHhJ5cKAjtU=.120d7264-cf75-46f1-814b-901470eaa867@github.com>
 <z_mmS863JDJH-rk_wBcbA6wq-3DUSe6Yc3oz2IyCPU8=.072d2f24-65be-4ffe-bf69-65fdf43b23ef@github.com>
Message-ID: <2_GWt8m_jh0Gd_wGVM_d30o8oazUQK3aiQPiJdOXH0Q=.986b9258-27c8-40d7-b0f1-9e94df3f6c3d@github.com>

On Wed, 12 Mar 2025 13:31:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Should we specify that the `@Deprecated` annotation on preview features be marked as `forRemoval=true`

wouldn't this send a wrong message?
could we invent a new annotation `@Preview` ?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1359#issuecomment-2718072925

From jhendrikx at openjdk.org  Wed Mar 12 14:40:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 12 Mar 2025 14:40:01 GMT
Subject: RFR: 8290310: ChangeListener events are incorrect or misleading
 when a nested change occurs [v16]
In-Reply-To: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
References: <-c9W_6MJ7b6-UeF6rp2AOjAGFYZGyd3poJo-LjXqj8s=.441d66bd-77f3-4947-bbc3-3d95d1da245c@github.com>
Message-ID: <Q2zWwhM_tIqcQK0MonInPUw_FI7QzO4Wd7W-GOThW24=.4451b172-ab70-4842-81a8-fdd5d0be0e16@github.com>

> This provides and uses a new implementation of `ExpressionHelper`, called `ListenerManager` with improved semantics.
> 
> See also #837 for a previous attempt which instead of triggering nested emissions immediately (like this PR and `ExpressionHelper`) would wait until the current emission finishes and then start a new (non-nested) emission.
> 
> # Behavior
> 
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they were registered, invalidation listeners always before change listeners|(unchanged)|
> |Removal during Notification|All listeners present when notification started are notified, but excluded for any nested changes|Listeners are removed immediately regardless of nesting|
> |Addition during Notification|Only listeners present when notification started are notified, but included for any nested changes|New listeners are never called during the current notification regardless of nesting|
> 
> ## Nested notifications:
> 
> | |ExpressionHelper|ListenerManager|
> |---|---|---|
> |Type|Depth first (call stack increases for each nested level)|(same)|
> |# of Calls|Listeners * Depth (using incorrect old values)|Collapses nested changes, skipping non-changes|
> |Vetoing Possible?|No|Yes|
> |Old Value correctness|Only for listeners called before listeners making nested changes|Always|
> 
> # Performance
> 
> |Listener|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Addition|Array based, append in empty slot, resize as needed|(same)|
> |Removal|Array based, shift array, resize as needed|(same)|
> |Addition during notification|Array is copied, removing collected WeakListeners in the process|Appended when notification finishes|
> |Removal during notification|As above|Entry is `null`ed (to avoid moving elements in array that is being iterated)|
> |Notification completion with changes|-|Null entries (and collected WeakListeners) are removed|
> |Notifying Invalidation Listeners|1 ns each|(same)|
> |Notifying Change Listeners|1 ns each (*)|2-3 ns each|
> 
> (*) a simple for loop is close to optimal, but unfortunately does not provide correct old values
> 
> # Memory Use 
> 
> Does not include alignment, and assumes a 32-bit VM or one that is using compressed oops.
> 
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes overhead|none|16 bytes overhead|
> |Multiple listeners|57 + 4 per listener (excluding unused slots)|57 + 4 per listener...

John Hendrikx has updated the pull request incrementally with two additional commits since the last revision:

 - Change StackOverflowException to warning log
 - Support keeping last message in Logging helper

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1081/files
  - new: https://git.openjdk.org/jfx/pull/1081/files/10af6ace..48364cc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=15
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1081&range=14-15

  Stats: 112 lines in 5 files changed: 62 ins; 22 del; 28 mod
  Patch: https://git.openjdk.org/jfx/pull/1081.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1081/head:pull/1081

PR: https://git.openjdk.org/jfx/pull/1081

From kcr at openjdk.org  Wed Mar 12 14:43:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 12 Mar 2025 14:43:03 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v3]
In-Reply-To: <2_GWt8m_jh0Gd_wGVM_d30o8oazUQK3aiQPiJdOXH0Q=.986b9258-27c8-40d7-b0f1-9e94df3f6c3d@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <QPXmSEUzZvGAYiSXG9EAUBviG_AIeHFmuHhJ5cKAjtU=.120d7264-cf75-46f1-814b-901470eaa867@github.com>
 <z_mmS863JDJH-rk_wBcbA6wq-3DUSe6Yc3oz2IyCPU8=.072d2f24-65be-4ffe-bf69-65fdf43b23ef@github.com>
 <2_GWt8m_jh0Gd_wGVM_d30o8oazUQK3aiQPiJdOXH0Q=.986b9258-27c8-40d7-b0f1-9e94df3f6c3d@github.com>
Message-ID: <hSuX1kpJ5N9X54_Wzz_fG8PR9FS0tYlmq2xGf2_U9pg=.b78bd5f9-663b-4c65-9a8f-f5a1ec5cbd4f@github.com>

On Wed, 12 Mar 2025 14:24:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Should we specify that the `@Deprecated` annotation on preview features be marked as `forRemoval=true`
> 
> wouldn't this send a wrong message?

Yes, that's the main counter-argument. Unlike incubator modules, which necessarily need to move elsewhere when finalized, there is a very good chance that a preview feature API will not change. So let's shelf the notion of `forRemoval=true`.

> could we invent a new annotation `@Preview` ?

That's an interesting idea, but probably not, at least not without a lot more effort. We would need to ship the annotation as part of `javafx.base`, since it would need runtime retention (so that javac and IDEs would be able to display it). We would also need to add a similar javadoc tag.

@mstr2 I presume you initially considered something like this?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1359#issuecomment-2718126813

From john.hendrikx at gmail.com  Wed Mar 12 14:52:17 2025
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Wed, 12 Mar 2025 15:52:17 +0100
Subject: Probably bug: UI changes made while minimized, not reflected upon
 restore/maximize
In-Reply-To: <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
References: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
 <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
Message-ID: <947195b9-cfc2-42d6-b269-8265c4ab78d4@gmail.com>

Here's a simpler version that shows the problem. It appears that a stage
in iconified mode (minimized) is simply not doing any updates when it
becomes visible again. In my system, when I click the task bar to show
the stage, I just see an empty box (with a color that is clearly not the
correct background color). A resize will show the label, and the
background color changes to the correct one:

publicclassApp extendsApplication {

publicstaticvoidmain(String[] args) {

Application.launch(args);

}

@Override

publicvoidstart(Stage stage) {

Scene scene = newScene(newLabel("This should be modified when the signal
is received"), 500, 500);

stage.setScene(scene);

stage.setIconified(true);

stage.show();

}

}

--John

On 12/03/2025 02:36, Cormac Redmond wrote:
> That meant to say: the act of simply maximising the window
> ***doesn't*** seem to trigger a redraw.
>
>
> On Wed, 12 Mar 2025 at 00:19, Cormac Redmond <credmond at certak.com> wrote:
>
>     Hi all,
>
>     A user reported this on reddit:
>     https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/
>
>     I do feel this is a bug so?I'm raising it here. Windows 11, JFX
>     23.0.2.
>
>     A quick summary is: if you change a Label while your app is
>     minimized, for example, the change does not get reflected when
>     restored/maximised, unless _something else_ triggers a redraw,
>     such as a window resize, or a hover over a button, etc.?
>
>     The act of simply maximising the window does seem to trigger a
>     redraw. I think it should.
>
>     Here are two fairly self-explanatory Java classes to demonstrate
>     the problem (adapted from the reddit post).
>
>     Steps:?
>
>     - Run MinimizeBugApp, observe label
>     - Run Client, hit enter and observe label change as expected
>     - Minimize app, and hit enter on Client one or more times (all
>     triggering label changes)
>     - Restore app, note Label incorrectly still *displays* the same
>     value as before the minimize, despite update(s)
>     - Re-size window to force a redraw, observe correct label value
>     appears
>
>
>     public class MinimizeBugApp extends Application {
>
>     ? ? public void start(Stage stage) {
>     ? ? ? ? Label label = new Label("This should be modified when the
>     signal is received");
>
>     ? ? ? ? StackPane stackPane = new StackPane();
>     ? ? ? ? stackPane.getChildren().add(label);
>     ? ? ? ? Scene scene = new Scene(stackPane, 500, 500);
>     ? ? ? ? stage.setScene(scene);
>     ? ? ? ? stage.show();
>
>     ? ? ? ? new Thread(() -> {
>     ? ? ? ? ? ? this.startServer(label);
>     ? ? ? ? }).start();
>     ? ? }
>
>     ? ? void startServer(final Label label) {
>     ? ? ? ? try (ServerSocket serverSocket = new ServerSocket(1590)) {
>     ? ? ? ? ? ? while (true) {
>     ? ? ? ? ? ? ? ? System.out.println("Waiting for connection...");
>     ? ? ? ? ? ? ? ? serverSocket.accept();
>     ? ? ? ? ? ? ? ? Platform.runLater(() -> {
>     ? ? ? ? ? ? ? ? ? ? System.out.println("Setting signal is
>     received...");
>     ? ? ? ? ? ? ? ? ? ? label.setText("The signal is received " + new
>     Date());
>
>     ? ? ? ? ? ? ? ? ? ? // This will print the correct text, always --
>     but the texted isn't what is reflected if
>     ? ? ? ? ? ? ? ? ? ? // it's minimized and then maximized
>     ? ? ? ? ? ? ? ? ? ? System.out.println("Label text should be: " +
>     label.getText());
>     ? ? ? ? ? ? ? ? });
>     ? ? ? ? ? ? }
>     ? ? ? ? } catch (Exception e) {
>     ? ? ? ? ? ? e.printStackTrace();
>     ? ? ? ? }
>     ? ? }
>
>     ? ? public static void main(String[] args) {
>     ? ? ? ? launch();
>     ? ? }
>     }
>
>
>     // Simple test to trigger something in a JavaFX app via a socket
>     public class Client {
>     ? ? public static void main(String[] args) {
>     ? ? ? ? Scanner scanner = new Scanner(System.in);
>
>     ? ? ? ? while (true) {
>     ? ? ? ? ? ? try {
>     ? ? ? ? ? ? ? ? System.out.print("Hit enter to create connection");
>     ? ? ? ? ? ? ? ? scanner.nextLine();
>     ? ? ? ? ? ? ? ? new Socket("localhost", 1590);
>     ? ? ? ? ? ? ? ? System.out.println("Created connection");
>     ? ? ? ? ? ? } catch (IOException e) {
>     ? ? ? ? ? ? ? ??e.printStackTrace();
>     ? ? ? ? ? ? }
>     ? ? ? ? }
>     ? ? }
>     }
>
>
>     Any thoughts? Is this by design for some reason, or a bug?
>
>
>
>     Kind?Regards,
>     *
>     *
>     *Cormac Redmond*
>     Software Engineer, Certak Ltd.
>     *
>     *
>     e: credmond at certak.com | m: +353 (0) 86 268 2152 | w:
>     www.certak.com <http://www.certak.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/c655e6bc/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Mar 12 14:54:22 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 12 Mar 2025 14:54:22 +0000
Subject: Probably bug: UI changes made while minimized, not reflected upon
 restore/maximize
In-Reply-To: <947195b9-cfc2-42d6-b269-8265c4ab78d4@gmail.com>
References: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
 <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
 <947195b9-cfc2-42d6-b269-8265c4ab78d4@gmail.com>
Message-ID: <BYAPR10MB30135BB73232844687192698E5D02@BYAPR10MB3013.namprd10.prod.outlook.com>

Reproduced, thanks!  I am going to create a bug shortly.

-andy

From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Date: Wednesday, March 12, 2025 at 07:52
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Probably bug: UI changes made while minimized, not reflected upon restore/maximize

Here's a simpler version that shows the problem. It appears that a stage in iconified mode (minimized) is simply not doing any updates when it becomes visible again. In my system, when I click the task bar to show the stage, I just see an empty box (with a color that is clearly not the correct background color). A resize will show the label, and the background color changes to the correct one:

public class App extends Application {

public static void main(String[] args) {

Application.launch(args);

}

@Override

public void start(Stage stage) {

Scene scene = new Scene(new Label("This should be modified when the signal is received"), 500, 500);

stage.setScene(scene);

stage.setIconified(true);

stage.show();

}

}

--John
On 12/03/2025 02:36, Cormac Redmond wrote:
That meant to say: the act of simply maximising the window ***doesn't*** seem to trigger a redraw.


On Wed, 12 Mar 2025 at 00:19, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi all,

A user reported this on reddit: https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/

I do feel this is a bug so I'm raising it here. Windows 11, JFX 23.0.2.

A quick summary is: if you change a Label while your app is minimized, for example, the change does not get reflected when restored/maximised, unless _something else_ triggers a redraw, such as a window resize, or a hover over a button, etc.

The act of simply maximising the window does seem to trigger a redraw. I think it should.

Here are two fairly self-explanatory Java classes to demonstrate the problem (adapted from the reddit post).

Steps:

- Run MinimizeBugApp, observe label
- Run Client, hit enter and observe label change as expected
- Minimize app, and hit enter on Client one or more times (all triggering label changes)
- Restore app, note Label incorrectly still *displays* the same value as before the minimize, despite update(s)
- Re-size window to force a redraw, observe correct label value appears


public class MinimizeBugApp extends Application {

    public void start(Stage stage) {
        Label label = new Label("This should be modified when the signal is received");

        StackPane stackPane = new StackPane();
        stackPane.getChildren().add(label);
        Scene scene = new Scene(stackPane, 500, 500);
        stage.setScene(scene);
        stage.show();

        new Thread(() -> {
            this.startServer(label);
        }).start();
    }

    void startServer(final Label label) {
        try (ServerSocket serverSocket = new ServerSocket(1590)) {
            while (true) {
                System.out.println("Waiting for connection...");
                serverSocket.accept();
                Platform.runLater(() -> {
                    System.out.println("Setting signal is received...");
                    label.setText("The signal is received " + new Date());

                    // This will print the correct text, always -- but the texted isn't what is reflected if
                    // it's minimized and then maximized
                    System.out.println("Label text should be: " + label.getText());
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        launch();
    }
}


// Simple test to trigger something in a JavaFX app via a socket
public class Client {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        while (true) {
            try {
                System.out.print("Hit enter to create connection");
                scanner.nextLine();
                new Socket("localhost", 1590);
                System.out.println("Created connection");
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}


Any thoughts? Is this by design for some reason, or a bug?



Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<http://www.certak.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/d9401167/attachment-0001.htm>

From andy.goryachev at oracle.com  Wed Mar 12 15:06:19 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 12 Mar 2025 15:06:19 +0000
Subject: Probably bug: UI changes made while minimized, not reflected upon
 restore/maximize
In-Reply-To: <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
References: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
 <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
Message-ID: <BYAPR10MB301385306F7AE383D1EA3ED2E5D02@BYAPR10MB3013.namprd10.prod.outlook.com>

Thank you for reporting the issue!
I?ve created https://bugs.openjdk.org/browse/JDK-8351867

-andy


From: openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac Redmond <credmond at certak.com>
Date: Tuesday, March 11, 2025 at 18:36
To: openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
Subject: Re: Probably bug: UI changes made while minimized, not reflected upon restore/maximize
That meant to say: the act of simply maximising the window ***doesn't*** seem to trigger a redraw.


On Wed, 12 Mar 2025 at 00:19, Cormac Redmond <credmond at certak.com<mailto:credmond at certak.com>> wrote:
Hi all,

A user reported this on reddit: https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/

I do feel this is a bug so I'm raising it here. Windows 11, JFX 23.0.2.

A quick summary is: if you change a Label while your app is minimized, for example, the change does not get reflected when restored/maximised, unless _something else_ triggers a redraw, such as a window resize, or a hover over a button, etc.

The act of simply maximising the window does seem to trigger a redraw. I think it should.

Here are two fairly self-explanatory Java classes to demonstrate the problem (adapted from the reddit post).

Steps:

- Run MinimizeBugApp, observe label
- Run Client, hit enter and observe label change as expected
- Minimize app, and hit enter on Client one or more times (all triggering label changes)
- Restore app, note Label incorrectly still *displays* the same value as before the minimize, despite update(s)
- Re-size window to force a redraw, observe correct label value appears


public class MinimizeBugApp extends Application {

    public void start(Stage stage) {
        Label label = new Label("This should be modified when the signal is received");

        StackPane stackPane = new StackPane();
        stackPane.getChildren().add(label);
        Scene scene = new Scene(stackPane, 500, 500);
        stage.setScene(scene);
        stage.show();

        new Thread(() -> {
            this.startServer(label);
        }).start();
    }

    void startServer(final Label label) {
        try (ServerSocket serverSocket = new ServerSocket(1590)) {
            while (true) {
                System.out.println("Waiting for connection...");
                serverSocket.accept();
                Platform.runLater(() -> {
                    System.out.println("Setting signal is received...");
                    label.setText("The signal is received " + new Date());

                    // This will print the correct text, always -- but the texted isn't what is reflected if
                    // it's minimized and then maximized
                    System.out.println("Label text should be: " + label.getText());
                });
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        launch();
    }
}


// Simple test to trigger something in a JavaFX app via a socket
public class Client {
    public static void main(String[] args) {
        Scanner scanner = new Scanner(System.in);

        while (true) {
            try {
                System.out.print("Hit enter to create connection");
                scanner.nextLine();
                new Socket("localhost", 1590);
                System.out.println("Created connection");
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}


Any thoughts? Is this by design for some reason, or a bug?



Kind Regards,

Cormac Redmond
Software Engineer, Certak Ltd.

e: credmond at certak.com<mailto:credmond at certak.com> | m: +353 (0) 86 268 2152 | w: www.certak.com<http://www.certak.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/ef9f860a/attachment-0001.htm>

From credmond at certak.com  Wed Mar 12 15:30:36 2025
From: credmond at certak.com (Cormac Redmond)
Date: Wed, 12 Mar 2025 15:30:36 +0000
Subject: Probably bug: UI changes made while minimized,
 not reflected upon restore/maximize
In-Reply-To: <BYAPR10MB301385306F7AE383D1EA3ED2E5D02@BYAPR10MB3013.namprd10.prod.outlook.com>
References: <CAGBnJPuv-N03zGmnXS-=R-zx6q0DK12jv2FaKEYFkdFcvfhHAg@mail.gmail.com>
 <CAG_-AaBJ2c65MAqpTC68a-T7DxcGPbELUHc+FZ+Q=fHKMY2SZw@mail.gmail.com>
 <BYAPR10MB301385306F7AE383D1EA3ED2E5D02@BYAPR10MB3013.namprd10.prod.outlook.com>
Message-ID: <CAG_-AaB6DPGUDjL9awkL6AbdYGTZOZ3LfA65yJH1n1bwVjvZcg@mail.gmail.com>

Great -- thanks John & Andy!

On Wed, 12 Mar 2025 at 15:06, Andy Goryachev <andy.goryachev at oracle.com>
wrote:

> Thank you for reporting the issue!
>
> I?ve created https://bugs.openjdk.org/browse/JDK-8351867
>
>
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev <openjfx-dev-retn at openjdk.org> on behalf of Cormac
> Redmond <credmond at certak.com>
> *Date: *Tuesday, March 11, 2025 at 18:36
> *To: *openjfx-dev at openjdk.org <openjfx-dev at openjdk.org>
> *Subject: *Re: Probably bug: UI changes made while minimized, not
> reflected upon restore/maximize
>
> That meant to say: the act of simply maximising the window ***doesn't***
> seem to trigger a redraw.
>
>
>
>
>
> On Wed, 12 Mar 2025 at 00:19, Cormac Redmond <credmond at certak.com> wrote:
>
> Hi all,
>
>
>
> A user reported this on reddit:
> https://www.reddit.com/r/JavaFX/comments/1j8ibpf/platformrunlater_not_updating_the_content_when/
>
>
>
> I do feel this is a bug so I'm raising it here. Windows 11, JFX 23.0.2.
>
>
>
> A quick summary is: if you change a Label while your app is minimized, for
> example, the change does not get reflected when restored/maximised, unless
> _something else_ triggers a redraw, such as a window resize, or a hover
> over a button, etc.
>
>
>
> The act of simply maximising the window does seem to trigger a redraw. I
> think it should.
>
>
>
> Here are two fairly self-explanatory Java classes to demonstrate the
> problem (adapted from the reddit post).
>
>
>
> Steps:
>
>
>
> - Run MinimizeBugApp, observe label
>
> - Run Client, hit enter and observe label change as expected
>
> - Minimize app, and hit enter on Client one or more times (all triggering
> label changes)
>
> - Restore app, note Label incorrectly still *displays* the same value as
> before the minimize, despite update(s)
>
> - Re-size window to force a redraw, observe correct label value appears
>
>
>
>
>
> public class MinimizeBugApp extends Application {
>
>     public void start(Stage stage) {
>         Label label = new Label("This should be modified when the signal
> is received");
>
>         StackPane stackPane = new StackPane();
>         stackPane.getChildren().add(label);
>         Scene scene = new Scene(stackPane, 500, 500);
>         stage.setScene(scene);
>         stage.show();
>
>         new Thread(() -> {
>             this.startServer(label);
>         }).start();
>     }
>
>     void startServer(final Label label) {
>         try (ServerSocket serverSocket = new ServerSocket(1590)) {
>             while (true) {
>                 System.out.println("Waiting for connection...");
>                 serverSocket.accept();
>                 Platform.runLater(() -> {
>                     System.out.println("Setting signal is received...");
>                     label.setText("The signal is received " + new Date());
>
>                     // This will print the correct text, always -- but the
> texted isn't what is reflected if
>                     // it's minimized and then maximized
>                     System.out.println("Label text should be: " +
> label.getText());
>                 });
>             }
>         } catch (Exception e) {
>             e.printStackTrace();
>         }
>     }
>
>     public static void main(String[] args) {
>         launch();
>     }
> }
>
>
>
>
>
> // Simple test to trigger something in a JavaFX app via a socket
> public class Client {
>     public static void main(String[] args) {
>         Scanner scanner = new Scanner(System.in);
>
>         while (true) {
>             try {
>                 System.out.print("Hit enter to create connection");
>                 scanner.nextLine();
>                 new Socket("localhost", 1590);
>                 System.out.println("Created connection");
>             } catch (IOException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
>
>
>
>
>
> Any thoughts? Is this by design for some reason, or a bug?
>
>
>
>
>
>
> Kind Regards,
>
>
>
> *Cormac Redmond*
>
> Software Engineer, Certak Ltd.
>
>
>
> e: credmond at certak.com | m: +353 (0) 86 268 2152 | w: www.certak.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250312/5f4bd6d6/attachment.htm>

From john at status6.com  Wed Mar 12 19:11:14 2025
From: john at status6.com (John Neffenger)
Date: Wed, 12 Mar 2025 12:11:14 -0700
Subject: Building OpenJFX with the JDK build system
In-Reply-To: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
References: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
Message-ID: <bddd8b07-e779-4d96-ae6f-82e2199be4bc@status6.com>

On 2/27/25 7:15 AM, Johan Vos wrote:
> The POC I have for this (linux-only at the moment) is at
> https://github.com/johanvos/jdk/tree/jfxpoc-blog

That's very clever, Johan. I never thought of using the JDK repository 
as-is to build JavaFX. I agree it's "one of the most excellent build 
systems for software development today," so what a great idea to start 
with that!

Your "proof of concept" repository builds successfully for me on Ubuntu 
22.04 LTS and goes rather smoothly through the JavaFX modules:

     Compiling up to 1 files for java.se
  -> Compiling up to 312 files for javafx.base
     Compiling up to 18 files for jdk.accessibility
     Compiling up to 3 files for jdk.editpad
     Compiling up to 904 files for jdk.hotspot.agent
     Compiling up to 64 files for jdk.jconsole
     Compiling up to 69 files for jdk.jpackage
     Compiling up to 8 files for jdk.unsupported.desktop
  -> Compiling up to 1695 files for javafx.graphics
  -> Compiling up to 296 files for javafx.controls

The only rough edges are the 'javac' notes about deprecated APIs and 
unchecked or unsafe operations in use by JavaFX. Also, as you note, the 
'gcc' warnings are a bit jarring when you're accustomed to the sparse 
output of the JDK build by itself.

After the build, the JavaFX JMOD files are found in the right place:

$ ls build/linux-x86_64-server-release/images/jdk/jmods/javafx*
build/linux-x86_64-server-release/images/jdk/jmods/javafx.base.jmod
build/linux-x86_64-server-release/images/jdk/jmods/javafx.controls.jmod
build/linux-x86_64-server-release/images/jdk/jmods/javafx.graphics.jmod

and the runtime image includes over 4,000 JavaFX classes:

$ jimage list build/linux-x86_64-server-release/images/jdk/lib/modules \
     | grep javafx | wc -l
4009

I tested it with a "Hello World" JavaFX application on Ubuntu 24.04 LTS, 
and it worked fine except for a minor error:

$ opt/jdk/bin/java --enable-native-access=javafx.graphics \
     -jar tmp/dist/hello-javafx-1.0.0.jar
Mar 12, 2025 7:04:06 PM com.sun.javafx.css.StyleManager loadStylesheet
WARNING: Resource "com/sun/javafx/scene/control/skin/modena/modena.css"
not found.
Hello World!

So when can we switch?! :-)

Thanks,
John


From mstrauss at openjdk.org  Thu Mar 13 03:29:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Mar 2025 03:29:28 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v4]
In-Reply-To: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
Message-ID: <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>

> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  warning can be suppressed

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1359/files
  - new: https://git.openjdk.org/jfx/pull/1359/files/0a2a48b4..8ed78967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=02-03

  Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1359.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359

PR: https://git.openjdk.org/jfx/pull/1359

From mstrauss at openjdk.org  Thu Mar 13 03:38:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Mar 2025 03:38:58 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v3]
In-Reply-To: <2_GWt8m_jh0Gd_wGVM_d30o8oazUQK3aiQPiJdOXH0Q=.986b9258-27c8-40d7-b0f1-9e94df3f6c3d@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <QPXmSEUzZvGAYiSXG9EAUBviG_AIeHFmuHhJ5cKAjtU=.120d7264-cf75-46f1-814b-901470eaa867@github.com>
 <z_mmS863JDJH-rk_wBcbA6wq-3DUSe6Yc3oz2IyCPU8=.072d2f24-65be-4ffe-bf69-65fdf43b23ef@github.com>
 <2_GWt8m_jh0Gd_wGVM_d30o8oazUQK3aiQPiJdOXH0Q=.986b9258-27c8-40d7-b0f1-9e94df3f6c3d@github.com>
Message-ID: <LfiK74sQyroDJAFlko0LHlEq4uin1TPOVYF66R53Sus=.556c8a78-eb3c-448b-81c4-164d945c8dd3@github.com>

On Wed, 12 Mar 2025 14:24:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> > Should we specify that the `@Deprecated` annotation on preview features be marked as `forRemoval=true`
> 
> wouldn't this send a wrong message? could we invent a new annotation `@Preview` ?

We could, but then we'd lose the integration that the `@Deprecated` annotation has in IDEs. For example, IntelliJ shows you visually that you're using a deprecated API, which helps with discoverability.

> @mstr2 I presume you initially considered something like this?

I've chosen the `@Deprecated` annotation because, according to its documentation, it's supposed to be used for this very situation:

`An element may be deprecated for any of several reasons, for example, [...] it may be changed incompatibly or removed in a future version [...]`

Notable, the annotation was used for preview APIs in JDK 12 and 13, so there is precedent.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1359#issuecomment-2719751519

From mstrauss at openjdk.org  Thu Mar 13 03:49:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Mar 2025 03:49:03 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v4]
In-Reply-To: <BdaT6ghnr5NSs0EL1u2WyFxphagRmHcos8ZzsPOibFw=.20c1dfbe-444c-4fe4-bb9c-d5fdfc51aadd@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <BdaT6ghnr5NSs0EL1u2WyFxphagRmHcos8ZzsPOibFw=.20c1dfbe-444c-4fe4-bb9c-d5fdfc51aadd@github.com>
Message-ID: <2Rl4DJuRx_y8yB17NKblInIs5ipanubW0VF5qxlTiMs=.6fa4432f-f172-4b98-a416-b27b407dd370@github.com>

On Mon, 10 Mar 2025 20:30:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Summary
>> -------
>> 
>> Adds a thread check to a number of `Platform` methods:
>> 
>> accessibilityActiveProperty()
>> getPreferences()
>> isAccessibilityActive()
>> 
>> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
>> 
>> Problem
>> -------
>> 
>> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
>> 
>> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
>> 
>> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
>> 
>> Solution
>> --------
>> 
>> Fail each method fast with an  `IllegalStateException` if called from a background thread.
>> 
>> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get preferences

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1728#pullrequestreview-2680408534

From mstrauss at openjdk.org  Thu Mar 13 04:03:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 13 Mar 2025 04:03:04 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <JA-mMH8okq0yOWPq7n1O_giSQVgckc1sbAAfbp85j2I=.44ac9be1-ce95-4252-b31f-445259db7a64@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 233:

> 231: 
> 232:         if (Platform.isFxApplicationThread()) {
> 233:             if (Toolkit.getToolkit().getSystemMenu().isSupported()) {

You could move this check to the outer scope, because if it evalutes to false, we can skip both branches of `if (Platform.isFxApplicationThread()) {` completely.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1727#discussion_r1992698653

From jbhaskar at openjdk.org  Thu Mar 13 05:08:39 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Thu, 13 Mar 2025 05:08:39 GMT
Subject: RFR: 8351653: Webkit debug build failure after update to 620.1
Message-ID: <gjLnuFERz_U2hOsLtELF6Fa5xfUXIk_z-6XyXiXsgzs=.51286476-d31f-4800-b0e6-a7ca818c809e@github.com>

issue : build fails on debug mode. invalid casting
Solution: the casting should be with char* , need to use SourceUTF8().data()

-------------

Commit messages:
 - 8351653: Webkit debug build failure after update to 620.1

Changes: https://git.openjdk.org/jfx/pull/1732/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1732&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351653
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1732.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1732/head:pull/1732

PR: https://git.openjdk.org/jfx/pull/1732

From jhendrikx at openjdk.org  Thu Mar 13 10:41:31 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Mar 2025 10:41:31 GMT
Subject: RFR: 8351867: No UI changes while iconified
Message-ID: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>

Adds code to trigger a scene update when a Window is restored

This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

-------------

Commit messages:
 - Ensure a redraw is performed after windows is restored

Changes: https://git.openjdk.org/jfx/pull/1733/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1733&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351867
  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1733.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1733/head:pull/1733

PR: https://git.openjdk.org/jfx/pull/1733

From mfox at openjdk.org  Thu Mar 13 13:47:08 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 13 Mar 2025 13:47:08 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <504Pg1TfUgLCu1ny9zxByJAm4Lpkmv_IektmgrtHP8o=.775c34a7-e892-4304-8bdf-6a59d5c9913f@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

When the window is restored glass calls notifySize with RESTORED and then notifyRepaint with valid dimensions. Why is the repaint being dropped?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721311967

From jhendrikx at openjdk.org  Thu Mar 13 13:56:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Mar 2025 13:56:01 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <504Pg1TfUgLCu1ny9zxByJAm4Lpkmv_IektmgrtHP8o=.775c34a7-e892-4304-8bdf-6a59d5c9913f@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <504Pg1TfUgLCu1ny9zxByJAm4Lpkmv_IektmgrtHP8o=.775c34a7-e892-4304-8bdf-6a59d5c9913f@github.com>
Message-ID: <bIkFLMIL4epzsVImmsCQ4eTA62JJXYXoeIC-RV3YIrk=.f10d0a6b-f951-41c1-8308-dea78d60447e@github.com>

On Thu, 13 Mar 2025 13:43:55 GMT, Martin Fox <mfox at openjdk.org> wrote:

> When the window is restored glass calls notifySize with RESTORED and then notifyRepaint with valid dimensions. Why is the repaint being dropped?

Can you give me a bit more detail what you mean here?  I suspect it might be related to the size not actually changing, and so a size update with the same size does nothing?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721344390

From mfox at openjdk.org  Thu Mar 13 14:33:08 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 13 Mar 2025 14:33:08 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <bIkFLMIL4epzsVImmsCQ4eTA62JJXYXoeIC-RV3YIrk=.f10d0a6b-f951-41c1-8308-dea78d60447e@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <504Pg1TfUgLCu1ny9zxByJAm4Lpkmv_IektmgrtHP8o=.775c34a7-e892-4304-8bdf-6a59d5c9913f@github.com>
 <bIkFLMIL4epzsVImmsCQ4eTA62JJXYXoeIC-RV3YIrk=.f10d0a6b-f951-41c1-8308-dea78d60447e@github.com>
Message-ID: <Kj4GNTFABGbC7wWV5rqGj5lITiwY0GHkc_rj4Un6jE8=.cfedf889-e247-4f07-b345-5cacac6cd199@github.com>

On Thu, 13 Mar 2025 13:53:11 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Can you give me a bit more detail what you mean here? I suspect it might be related to the size not actually changing, and so a size update with the same size does nothing?

Sorry, I'm asking a general question about how JavaFX deals with repaint events issued by the OS. I've never understood how JavaFX's painting model interfaces with OS level calls that expect drawing to occur on demand and synchronously. But that conversation should probably be moved to another forum.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721470498

From kcr at openjdk.org  Thu Mar 13 14:54:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 14:54:00 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <oeZLfu39ao99TNlgMki_LeapObAwkK20fw4Km0osrxQ=.7c78857e-6f7f-4a37-a9c8-f805f4c82dcc@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).

@arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721544217

From kcr at openjdk.org  Thu Mar 13 15:26:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 15:26:09 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v4]
In-Reply-To: <BdaT6ghnr5NSs0EL1u2WyFxphagRmHcos8ZzsPOibFw=.20c1dfbe-444c-4fe4-bb9c-d5fdfc51aadd@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <BdaT6ghnr5NSs0EL1u2WyFxphagRmHcos8ZzsPOibFw=.20c1dfbe-444c-4fe4-bb9c-d5fdfc51aadd@github.com>
Message-ID: <h7O_4lHULXv6GZt_Ys2UydkW7cQfgyKE3rUQtkWqUd8=.5d378e9d-1e65-4a5c-a67a-316b4f53b576@github.com>

On Mon, 10 Mar 2025 20:30:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Summary
>> -------
>> 
>> Adds a thread check to a number of `Platform` methods:
>> 
>> accessibilityActiveProperty()
>> getPreferences()
>> isAccessibilityActive()
>> 
>> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
>> 
>> Problem
>> -------
>> 
>> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
>> 
>> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
>> 
>> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
>> 
>> Solution
>> --------
>> 
>> Fail each method fast with an  `IllegalStateException` if called from a background thread.
>> 
>> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   get preferences

Looks good. I left one minor comment on the test.

tests/system/src/test/java/test/javafx/application/PlatformTest.java line 129:

> 127: 
> 128:     @Test
> 129:     public void accessibilityActiveNotOnFxThread() {

Minor: Since you now also test `Platform::getPreferences` you might consider renaming this test method.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1728#pullrequestreview-2682396958
PR Review Comment: https://git.openjdk.org/jfx/pull/1728#discussion_r1993769589

From kcr at openjdk.org  Thu Mar 13 15:35:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 15:35:03 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v4]
In-Reply-To: <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
Message-ID: <a2jItqLc7oUjq4VzY3pUrXDSh_TQMsMRsQznI0LktIw=.424dab30-0ba6-4372-9a76-65eadeca28d6@github.com>

On Thu, 13 Mar 2025 03:29:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning can be suppressed

Thanks for the explanation. That all seems good to me. To summarize, we'll use the `@Deprecated` annotation (without the `forRemoval` parameter), and also use the `@deprecated` javadoc tag.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1359#issuecomment-2721676423

From kcr at openjdk.org  Thu Mar 13 15:38:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 15:38:16 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v4]
In-Reply-To: <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
Message-ID: <vV7nFv1PLB2j_BEnzU2alrAcg8kEUOuy06EUpAyjsNw=.be4a645c-4a2a-48ee-8ffd-a387f5248e33@github.com>

On Thu, 13 Mar 2025 03:29:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning can be suppressed

Looks good, with one naming suggestion.

modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 50:

> 48: 
> 49:     private static final String ENABLE_PREVIEW_PROPERTY = "javafx.enablePreview";
> 50:     private static final String SUPPRESS_WARNING_PROPERTY = "javafx.suppressPreviewBanner";

Perhaps `javafx.suppressPreviewWarning` would be a better name?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2682439226
PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1993794327

From angorya at openjdk.org  Thu Mar 13 15:42:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 15:42:36 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v5]
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <go2DiXpx474e5JWc1ofc7XJoWY8k5psmd6V50BQCd50=.1129c27a-64b9-4c4a-bc43-7018cc0b011d@github.com>

> Summary
> -------
> 
> Adds a thread check to a number of `Platform` methods:
> 
> accessibilityActiveProperty()
> getPreferences()
> isAccessibilityActive()
> 
> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
> 
> Problem
> -------
> 
> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
> 
> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
> 
> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
> 
> Solution
> --------
> 
> Fail each method fast with an  `IllegalStateException` if called from a background thread.
> 
> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - renamed
 - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
 - get preferences
 - enforce
 - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
 - review comments
 - javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1728/files
  - new: https://git.openjdk.org/jfx/pull/1728/files/e9bb3403..2fc3f9db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1728&range=03-04

  Stats: 485 lines in 15 files changed: 425 ins; 28 del; 32 mod
  Patch: https://git.openjdk.org/jfx/pull/1728.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1728/head:pull/1728

PR: https://git.openjdk.org/jfx/pull/1728

From jhendrikx at openjdk.org  Thu Mar 13 15:48:02 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Mar 2025 15:48:02 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <oeZLfu39ao99TNlgMki_LeapObAwkK20fw4Km0osrxQ=.7c78857e-6f7f-4a37-a9c8-f805f4c82dcc@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <oeZLfu39ao99TNlgMki_LeapObAwkK20fw4Km0osrxQ=.7c78857e-6f7f-4a37-a9c8-f805f4c82dcc@github.com>
Message-ID: <eZ8wTPMs0q5uSbVt4EU67zufiLUA3opLI1C--cmxWLY=.395e581e-1a05-4544-bb23-b0164d233884@github.com>

On Thu, 13 Mar 2025 14:51:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).
> 
> @arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.

Yeah, I'm sort of mimicking what happens when a RESCALE or MOVE occurs, so it is similar to what some of the other handlers do (MOVE does `updateSceneState`, and RESCALE does that and `entireSceneNeedsRepaint`).  I'm not that well versed in the differences between these two, but it seemed not a bad place to fix this as restores happen very rarely.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721719308

From angorya at openjdk.org  Thu Mar 13 15:55:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 15:55:01 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v4]
In-Reply-To: <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
Message-ID: <3ktB8PQ2zz1ITdSxfDnCRdrlycG4LfnrjQvVJmUhSgs=.7acae56c-dd48-4ba8-8218-a16a88c99d57@github.com>

On Thu, 13 Mar 2025 03:29:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning can be suppressed

needs a CSR now.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2682501716

From kcr at openjdk.org  Thu Mar 13 16:15:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 16:15:07 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v5]
In-Reply-To: <go2DiXpx474e5JWc1ofc7XJoWY8k5psmd6V50BQCd50=.1129c27a-64b9-4c4a-bc43-7018cc0b011d@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <go2DiXpx474e5JWc1ofc7XJoWY8k5psmd6V50BQCd50=.1129c27a-64b9-4c4a-bc43-7018cc0b011d@github.com>
Message-ID: <L416eF_xNzTUGQ94EZ7FFxO37ZXqIXdGiOStBU9-Lc8=.f85ab396-1e0a-4cc1-a17c-1975eb0213db@github.com>

On Thu, 13 Mar 2025 15:42:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Summary
>> -------
>> 
>> Adds a thread check to a number of `Platform` methods:
>> 
>> accessibilityActiveProperty()
>> getPreferences()
>> isAccessibilityActive()
>> 
>> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
>> 
>> Problem
>> -------
>> 
>> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
>> 
>> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
>> 
>> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
>> 
>> Solution
>> --------
>> 
>> Fail each method fast with an  `IllegalStateException` if called from a background thread.
>> 
>> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - renamed
>  - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
>  - get preferences
>  - enforce
>  - Merge remote-tracking branch 'origin/master' into 8351067.accessibility
>  - review comments
>  - javadoc

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1728#pullrequestreview-2682584857

From angorya at openjdk.org  Thu Mar 13 16:15:06 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 16:15:06 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <eZ8wTPMs0q5uSbVt4EU67zufiLUA3opLI1C--cmxWLY=.395e581e-1a05-4544-bb23-b0164d233884@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <oeZLfu39ao99TNlgMki_LeapObAwkK20fw4Km0osrxQ=.7c78857e-6f7f-4a37-a9c8-f805f4c82dcc@github.com>
 <eZ8wTPMs0q5uSbVt4EU67zufiLUA3opLI1C--cmxWLY=.395e581e-1a05-4544-bb23-b0164d233884@github.com>
Message-ID: <bSckqjPP1xWug0WagpIoGJFdazuPnr1agC3JZaqmUkM=.6c44e8ca-b045-4c30-80b6-b1ec06496c91@github.com>

On Thu, 13 Mar 2025 15:45:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).
>> 
>> @arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.
>
>> My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).
>> 
>> @arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.
> 
> Yeah, I'm sort of mimicking what happens when a RESCALE or MOVE occurs, so it is similar to what some of the other handlers do (MOVE does `updateSceneState`, and RESCALE does that and `entireSceneNeedsRepaint`).  I'm not that well versed in the differences between these two, but it seemed not a bad place to fix this as restores happen very rarely.

@hjohn this did not fix the issue for me on macOS 15.3.1 M1
(the reproducer still shows "Initial State" label)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721810045

From kcr at openjdk.org  Thu Mar 13 16:15:06 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 16:15:06 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <pRQ3dnAE9bKEidCif3RlsxJCx-E39vFqBM4wWuImIKo=.1fe71a7b-a8ae-4453-bf80-7a5aba1b3a03@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

Yeah, your solution might be fine. I just wanted to take a look at an alternative (or rather ask Ambarish to).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2721830062

From angorya at openjdk.org  Thu Mar 13 16:21:04 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 16:21:04 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <JA-mMH8okq0yOWPq7n1O_giSQVgckc1sbAAfbp85j2I=.44ac9be1-ce95-4252-b31f-445259db7a64@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
 <JA-mMH8okq0yOWPq7n1O_giSQVgckc1sbAAfbp85j2I=.44ac9be1-ce95-4252-b31f-445259db7a64@github.com>
Message-ID: <iTreKMwmWf1mytKoinZtypHXKYZgW5eIur4tDZe2zDA=.4657fde2-0f3d-4e14-916b-51f7eef97ce5@github.com>

On Thu, 13 Mar 2025 04:00:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>>  - spelling
>>  - use system menu
>>  - cleanup
>>  - possible fix
>>  - test
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuBarSkin.java line 233:
> 
>> 231: 
>> 232:         if (Platform.isFxApplicationThread()) {
>> 233:             if (Toolkit.getToolkit().getSystemMenu().isSupported()) {
> 
> You could move this check to the outer scope, because if it evalutes to false, we can skip both branches of `if (Platform.isFxApplicationThread()) {` completely.

not sure what you mean exactly.
Toolkit.getToolkit().getSystemMenu().isSupported() must be called in the fx application thread, and the rest of the changes were done to minimize the structural changes.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1727#discussion_r1993874015

From snazarki at openjdk.org  Thu Mar 13 18:22:42 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Thu, 13 Mar 2025 18:22:42 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
Message-ID: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>

Hi!

This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.

#  What is the problem?
VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
Stack trace

    frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
    frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
    frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
    frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
    frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
    frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
    frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
    frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
    frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
    frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000001761e1200, image=0x000000016fdf7090) at BitmapImage.cpp:67:16
    frame #14: 0x00000003423a6b60 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000001761e1200, image=0x000000016fdf7090) at BitmapImage.cpp:68:1
    frame #15: 0x00000003423a6bd0 libjfxwebkit.dylib`WebCore::BitmapImage::create(nativeImage=0x000000016fdf70e0) at BitmapImage.cpp:52:26
    frame #16: 0x00000003416abcf0 libjfxwebkit.dylib`WebCore::HTMLCanvasElement::copiedImage(this=0x0000000321008640) const at HTMLCanvasElement.cpp:903:29
    frame #17: 0x0000000341899e70 libjfxwebkit.dylib`WebCore::CanvasRenderingContext2DBase::createPattern(this=0x0000000321008b00, canvas=0x0000000321008640, repeatX=true, repeatY=true) at CanvasRenderingContext2DBase.cpp:2232:32 


# Historical excavation
There was a similar problem in the [past](https://hg.openjdk.org/openjfx/10-dev/rt/rev/542116615e59).  The predecessor of `PlatformImageNativeImageBackend::size` knew that there is an `Image` (like gif with multiple frames, or still image) and ImageFrame.  But then it assumes "NativeImage" is always backed by `WCImageFrame`

# The fix
The fix restores original idea and checks the backend class.  The method returns zero size if the `m_platformImage` is not `WCImageFrame`


# The alternative
I believe there is a more straightforward and correct way to fix this. Don't hesitate to reject the PR if you know a better solution.

-------------

Commit messages:
 - 8347937: Canvas pattern test fails on WebKit 620.1

Changes: https://git.openjdk.org/jfx/pull/1734/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1734&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347937
  Stats: 19 lines in 3 files changed: 12 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1734.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1734/head:pull/1734

PR: https://git.openjdk.org/jfx/pull/1734

From kcr at openjdk.org  Thu Mar 13 18:53:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 18:53:01 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
Message-ID: <djTdlgezxbSbniiK2D7zD_ORfR8giRLvRusW58PV6po=.946afe2f-0b34-45de-bc20-154ca8fc3eb9@github.com>

On Thu, 13 Mar 2025 18:17:53 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
> 
> #  What is the problem?
> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
> Stack trace
> 
>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000...

Reviewers: @jaybhaskar @arapte (and/or me)

This looks more like a workaround than a fix, but if it avoids the crash, and is a sound solution, it might be worth doing as a stop-gap. We'd still need an actual fix in the native code. Jay can do an initial evaluation.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1734#issuecomment-2722385761

From angorya at openjdk.org  Thu Mar 13 22:06:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 22:06:17 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply formatting
Message-ID: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>

Fixed two issues found in importing RTF text:

- Arabic import
- missing font size

The former was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?

-------------

Commit messages:
 - font size
 - fixed arabic import

Changes: https://git.openjdk.org/jfx/pull/1735/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351878
  Stats: 157 lines in 3 files changed: 150 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jfx/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1735/head:pull/1735

PR: https://git.openjdk.org/jfx/pull/1735

From kcr at openjdk.org  Thu Mar 13 22:43:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 22:43:24 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
Message-ID: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>

> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 24:
> 
> https://bugs.openjdk.org/issues/?filter=46704
> 
> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).

Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:

 - Change JavaFX javadoc URLs to 24
 - Remove GStreamer and Glib updates that were superseded by later updates

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1712/files
  - new: https://git.openjdk.org/jfx/pull/1712/files/2cabc370..0f4e68f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1712&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1712.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1712/head:pull/1712

PR: https://git.openjdk.org/jfx/pull/1712

From angorya at openjdk.org  Thu Mar 13 22:43:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 13 Mar 2025 22:43:24 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
Message-ID: <qLvfcRzuHaRlIK87TT6Av4MHdaGVDLFJs_8TevnV6WM=.f88e9de8-8706-4441-b8e2-fc67b1ae7165@github.com>

On Thu, 13 Mar 2025 22:40:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change JavaFX javadoc URLs to 24
>  - Remove GStreamer and Glib updates that were superseded by later updates

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2683504411

From kcr at openjdk.org  Thu Mar 13 22:43:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 22:43:24 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <LToJrCRTuRbdsMc4ibUFrwW-ThfMc5uUA0gXcg-VOZE=.5fffccba-ddc5-44ef-aeec-9c1266702949@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
 <LToJrCRTuRbdsMc4ibUFrwW-ThfMc5uUA0gXcg-VOZE=.5fffccba-ddc5-44ef-aeec-9c1266702949@github.com>
Message-ID: <rRWsYLvvKC8lhUGLdE-vpm1Y6Mtv08_xxvbgDIEMpgM=.7d8d3005-46b4-4373-80ed-a792644f1b37@github.com>

On Tue, 11 Mar 2025 20:20:34 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> doc-files/release-notes-24.md line 154:
> 
>> 152: [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418) | [Linux] Replace obsolete XIM as Input Method Editor | window-toolkit
>> 153: 
>> 154: See the API docs for a list of [new APIs](https://openjfx.io/javadoc/23/new-list.html) and [deprecated APIs](https://openjfx.io/javadoc/23/deprecated-list.html) in each release.
> 
> I'll change this from 23 to 24 in the next commit.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1994386166

From kcr at openjdk.org  Thu Mar 13 22:43:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 22:43:24 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v3]
In-Reply-To: <tQwt4Gp1LOldGb3fw2wpfTHyiEEKVaRlSCzjT2NhMjM=.58440df6-13ee-495d-ac9a-742f2c227638@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Yo3-r9-gj78QTPwqo2aHQJxWCoVEhIhGmbWSBvFnHt8=.7fdd4aa5-3882-4fbf-9286-9c5db4da83ff@github.com>
 <S3wAw88BL030v164-bS67XECe3y8Zynz8BlZQhGp1J4=.5f4fc7fa-830b-448d-8aaf-b20c4663796b@github.com>
 <f5YJLmyZKb2Rf5167KgdMVu3YVdpcQiE2i18QyyBEN0=.9eb7b1e7-19b9-4392-85c1-0dbe9086f4c7@github.com>
 <tQwt4Gp1LOldGb3fw2wpfTHyiEEKVaRlSCzjT2NhMjM=.58440df6-13ee-495d-ac9a-742f2c227638@github.com>
Message-ID: <bN_RHlaeJ9j01oWWwW1YHemUNqj8YVHzTQZPW_j47tM=.39ce887d-83c1-4940-8125-0bb4d97d5eb3@github.com>

On Tue, 11 Mar 2025 20:57:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This is similar (but not quite the same) to the case of a bug that was introduced and fixed in the same release, which we exclude with the rationale that the end user or app developer who updates from one release to the next never sees the interim state. I can see a case for excluding these two third-party updates using the same reasoning.
>> 
>> What do others think? @hjohn @johanvos @andy-goryachev-oracle ?
>
>> I am in favor of keeping intermediary revisions for the same reason @kevinrushforth mentioned, and also because it eliminates manual filtering (?) and associated mistakes.
> 
> Actually, I was pointing out that it might be more consistent to _not_ keep them -- treating them like transiently introduced bugs -- but I can see both points. I'll let this percolate for a day or two and then we can decide.
> 
> By default I'll leave them in since that's what we've done in the past, but they add little value.

I decided to remove these two bugs. In addition to avoiding confusion, listing those two releases, which have publishes CVEs logged against them, will leave a mistaken impression that JavaFX is vulnerable to the bugs associated with those two older versions.

To address the filtering issues I defined two new labels: `javafx-rn-exclude` and `javafx-rn-include`, which can be applied to bugs and are used to filter in the same way that the `noreg-*` labels already are. The filter now has no manual list of bugs to include or exclude.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1994385908

From kcr at openjdk.org  Thu Mar 13 22:43:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 22:43:24 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
Message-ID: <PUlFEf3BZzop99ae-Kp4WgPFingHpIV0rbf6zfkbDk4=.492e0d1d-737f-4408-84bc-1017a8041467@github.com>

On Thu, 13 Mar 2025 22:40:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change JavaFX javadoc URLs to 24
>  - Remove GStreamer and Glib updates that were superseded by later updates

doc-files/release-notes-24.md line 154:

> 152: [JDK-8305418](https://bugs.openjdk.org/browse/JDK-8305418) | [Linux] Replace obsolete XIM as Input Method Editor | window-toolkit
> 153: 
> 154: See the API docs for a list of [new APIs](https://openjfx.io/javadoc/24/new-list.html) and [deprecated APIs](https://openjfx.io/javadoc/24/deprecated-list.html) in each release.

As noted earlier, these links will give a 404 until the JavaFX 24 docs are published on openjfx.io.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1994387527

From kcr at openjdk.org  Thu Mar 13 22:46:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 13 Mar 2025 22:46:08 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v4]
In-Reply-To: <cM2YDTcWhz-Asg6GzhBd6_J0sTDRvpT_Oc3ZQdwC25Q=.786d4c89-304e-47eb-9cd3-ce60e06338b8@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <Ow3Y9QXqsyweP7Hb0E0ksr2pb49RnEYOWf4gqxc9ysU=.e65a86e3-b9ab-457a-b92b-ade68aa8be60@github.com>
 <cM2YDTcWhz-Asg6GzhBd6_J0sTDRvpT_Oc3ZQdwC25Q=.786d4c89-304e-47eb-9cd3-ce60e06338b8@github.com>
Message-ID: <8MtF6pMv9-TXifdIN_g3IpCajhe1NPBcYh155vBc6WE=.e699597a-61d3-48e0-b96a-738d439d608f@github.com>

On Wed, 12 Mar 2025 13:56:58 GMT, Abhinay Agarwal <duke at openjdk.org> wrote:

>> Kevin Rushforth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> doc-files/release-notes-24.md line 50:
> 
>> 48: ```
>> 49: 
>> 50: NOTE: The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead.
> 
> Should the `NOTE` be changed to use Github supported [highlight using blockquote](https://github.com/orgs/community/discussions/16925):
> 
> 
>> [!NOTE]
>> The above will fail if you run your application with JDK 23 or earlier. JDK 24 is recommended when running JavaFX 24, but if you choose to run JavaFX 24 with an earlier JDK, use the `--module-path` option instead.

I'll leave this as is for now, since we are so close to release. I'd also want to check out what GitLab does with it  as well. This might be worth doing for next time.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1712#discussion_r1994390569

From jhendrikx at openjdk.org  Thu Mar 13 22:52:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Mar 2025 22:52:01 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <eZ8wTPMs0q5uSbVt4EU67zufiLUA3opLI1C--cmxWLY=.395e581e-1a05-4544-bb23-b0164d233884@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <oeZLfu39ao99TNlgMki_LeapObAwkK20fw4Km0osrxQ=.7c78857e-6f7f-4a37-a9c8-f805f4c82dcc@github.com>
 <eZ8wTPMs0q5uSbVt4EU67zufiLUA3opLI1C--cmxWLY=.395e581e-1a05-4544-bb23-b0164d233884@github.com>
Message-ID: <qsepdaUX-yTjMVVN1TQ5jnVXDQ3oIgpGDjPml66A5Dw=.86eccd95-7a62-4eeb-848a-5017b23e65a7@github.com>

On Thu, 13 Mar 2025 15:45:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).
>> 
>> @arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.
>
>> My thought on this bug was to fix it in the scenegraph, rather than forcing a complete repaint in the toolkit. The scenegraph tracks the state of what is dirty and would only need to repaint if something has changed (and probably only those parts that have changed).
>> 
>> @arapte Can you take a look at this and see what you think? I am not able to look at it for at least a week.
> 
> Yeah, I'm sort of mimicking what happens when a RESCALE or MOVE occurs, so it is similar to what some of the other handlers do (MOVE does `updateSceneState`, and RESCALE does that and `entireSceneNeedsRepaint`).  I'm not that well versed in the differences between these two, but it seemed not a bad place to fix this as restores happen very rarely.

> @hjohn this did not fix the issue for me on macOS 15.3.1 M1 (the reproducer still shows "Initial State" label)

@andy-goryachev-oracle Hm, I can't test it on Mac, but this solution works on Windows.  I just tested again with your reproducer, and it fails without this change and works with it.  Maybe someone with a Mac can take a closer look?

For mac, perhaps also do `entireSceneNeedsRepaint` and see if that fixes it?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2722847063

From jhendrikx at openjdk.org  Thu Mar 13 22:53:06 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Thu, 13 Mar 2025 22:53:06 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
Message-ID: <8ICcQo3C4JAOe6mZf_EBCQSM1edfbyTyZZErBalX_oc=.d06030a1-d949-47f0-bdf8-611dda0b94c7@github.com>

On Thu, 13 Mar 2025 22:43:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change JavaFX javadoc URLs to 24
>  - Remove GStreamer and Glib updates that were superseded by later updates

Marked as reviewed by jhendrikx (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2683526089

From nlisker at openjdk.org  Fri Mar 14 00:04:57 2025
From: nlisker at openjdk.org (Nir Lisker)
Date: Fri, 14 Mar 2025 00:04:57 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
Message-ID: <JvQVf28KoBfPXaCa59jzTpqp2B3jjE6N4dq0dpzTztw=.762f10ab-f7eb-47a9-a2e0-1c7b146cc819@github.com>

On Thu, 13 Mar 2025 22:43:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change JavaFX javadoc URLs to 24
>  - Remove GStreamer and Glib updates that were superseded by later updates

Marked as reviewed by nlisker (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1712#pullrequestreview-2683623383

From kcr at openjdk.org  Fri Mar 14 13:21:08 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:21:08 GMT
Subject: RFR: 8350136: Create release notes for JavaFX 24 [v5]
In-Reply-To: <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
 <tNYPXZgXq9O3y8bhpPvETz-GW2sRQU7LCpcFI0y1yLA=.8369c56d-15cd-4d09-b4a1-74957b45512c@github.com>
Message-ID: <nuhNRcSuGESp5ZKxKcdgEEXntnHPyCge1y3cwCzzeeM=.a70d8fe9-e02a-40a0-bb78-8f92405db366@github.com>

On Thu, 13 Mar 2025 22:43:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
>> 
>> The following filter was used to produce the list of issues fixed in JavaFX 24:
>> 
>> https://bugs.openjdk.org/issues/?filter=46704
>> 
>> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).
>
> Kevin Rushforth has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Change JavaFX javadoc URLs to 24
>  - Remove GStreamer and Glib updates that were superseded by later updates

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1712#issuecomment-2724661072

From kcr at openjdk.org  Fri Mar 14 13:21:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:21:09 GMT
Subject: Integrated: 8350136: Create release notes for JavaFX 24
In-Reply-To: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
References: <wGJ8xDyWknnZOlb7qnhFbAlohPdjyqWYuO9xaNpC9bc=.318ed2a1-bbe6-4cb5-b374-3a2debe195d1@github.com>
Message-ID: <bSlRDZFpiGj7xo-UA3r5YpImv_9taOdD4pXY4K1x5zc=.9f5d372c-83ef-4884-b19f-a1345756e672@github.com>

On Fri, 14 Feb 2025 23:15:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR adds the release notes for the JavaFX 24 release. This will first go into master, and then be backported to the jfx24 branch so it will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> The following filter was used to produce the list of issues fixed in JavaFX 24:
> 
> https://bugs.openjdk.org/issues/?filter=46704
> 
> Additionally, we had seven issues with a release-note=yes label, which are included in the list of important changes, etc (one of them is still pending the text for the release note).

This pull request has now been integrated.

Changeset: d2ab2c89
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/d2ab2c89fcb1dce3c3f1ccb9f031e77cefe6ddbc
Stats:     275 lines in 2 files changed: 275 ins; 0 del; 0 mod

8350136: Create release notes for JavaFX 24

Reviewed-by: angorya, jhendrikx, nlisker

-------------

PR: https://git.openjdk.org/jfx/pull/1712

From kcr at openjdk.org  Fri Mar 14 13:25:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:25:13 GMT
Subject: [jfx24] RFR: 8350136: Create release notes for JavaFX 24
Message-ID: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>

Clean backport of the JavaFX 24 release notes to the `jfx24` stabilization branch, so they will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).

NOTE: The release notes are not part of the build, so this backport to jfx24 will not cause a respin of JavaFX 24.

-------------

Commit messages:
 - Backport d2ab2c89fcb1dce3c3f1ccb9f031e77cefe6ddbc

Changes: https://git.openjdk.org/jfx/pull/1736/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350136
  Stats: 275 lines in 2 files changed: 275 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1736.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1736/head:pull/1736

PR: https://git.openjdk.org/jfx/pull/1736

From kcr at openjdk.org  Fri Mar 14 13:29:57 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:29:57 GMT
Subject: [jfx24] RFR: 8350136: Create release notes for JavaFX 24
In-Reply-To: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
References: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
Message-ID: <jlYMfrK8ERGwflCwkm94h5BOgIy_CFhpNeDmdFeN0-E=.0b3662ca-f890-4655-a949-ab14f0d331d4@github.com>

On Fri, 14 Mar 2025 13:20:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 24 release notes to the `jfx24` stabilization branch, so they will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx24 will not cause a respin of JavaFX 24.

@andy-goryachev-oracle or @johanvos : can one of you review?

(since it is a clean backport, only a single reviewer is needed)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1736#issuecomment-2724705463

From kcr at openjdk.org  Fri Mar 14 13:37:09 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:37:09 GMT
Subject: RFR: 8351067: Enforce Platform threading use [v3]
In-Reply-To: <hjfXscOdZ3h88g_n5MpNZqtb6rcoBNqW3GPHkdUQAzc=.42481c71-fa1b-4342-a948-28f9216997d3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
 <9XDBC7JIQttXtzMENEdcibaD5i5GxekL2uLvyCwGdGs=.e532e044-0508-4003-82b6-ee6f47574ab4@github.com>
 <S4B47xvhEEC58ApebjTiJPlnLGm4494mjfK1gfhu5j4=.8ff53633-45c7-4d53-9c84-7de2d2f499bc@github.com>
 <31uE4mkMZQJtxj5WobaVCeLxt1ZujsPH9e4qn_RULOM=.d4679075-bc7b-4d44-a151-eb209f2ed42a@github.com>
 <L6juScyp3PE0P44gZdj21G8PUw7qhPWfJxwGfTKt13E=.5c8aafcc-b6dc-4069-bdb4-f4c94c0ad82f@github.com>
 <hjfXscOdZ3h88g_n5MpNZqtb6rcoBNqW3GPHkdUQAzc=.42481c71-fa1b-4342-a948-28f9216997d3@github.com>
Message-ID: <LroUl_lsIhlzwSV-nZsXv0ncqulch89HtuU_HG5gAXw=.a8bd8671-ddc6-46d3-9162-0081edc1874c@github.com>

On Fri, 7 Mar 2025 21:59:10 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>>> move to a more structured form of documentation, for example with custom javadoc tags.
>> 
>> what custom tags?  could you elaborate?
>
>> what custom tags? could you elaborate?
> 
> Maybe a custom tag like `@threadAccess JavaFX application thread`. This would then show up in the generated property list instead of the summary text. We already do this for `@interpolationType`.

The only change since @mstr2 approved this PR is to the name of a test method. As such, a single re-review should be sufficient, which I've already done, so I'm lowering the (re)review requirement down to 1 to reflect this.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1728#issuecomment-2724731041

From kcr at openjdk.org  Fri Mar 14 13:39:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 13:39:07 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v4]
In-Reply-To: <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <TIrd96t8iIau_8eYHAku3Ov_1obK0fuWWERGS6TKXnk=.a5ce2602-a014-4b01-937c-26ec4732301e@github.com>
Message-ID: <QZ5EsSwA9cyt6X8X9gEcfRE3qxlN_IqkCXcwxqRyCB8=.ceb30689-6a68-463b-aec3-179ad1762c44@github.com>

On Thu, 13 Mar 2025 03:29:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   warning can be suppressed

I'm approving this PR and will re-review if you change the name (which I recommend).

Go ahead and create the CSR when you get a chance.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2685589518

From kcr at openjdk.org  Fri Mar 14 14:14:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 14:14:58 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
Message-ID: <bZX28J6RaggptxIXD1heEyXS65nXA0uBXN_RilYLUlA=.4aee5a5d-4075-4c0f-89b9-0d6717eef2fc@github.com>

On Thu, 13 Mar 2025 18:17:53 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
> 
> #  What is the problem?
> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
> Stack trace
> 
>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000...

Initial testing shows that while this does prevent the crash, it doesn't actually render anything in the failing case.

@jaybhaskar will add more detail on Monday. He and @Gopalora are working on an actual fix.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1734#issuecomment-2724823745

From mfox at openjdk.org  Fri Mar 14 14:20:58 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 14 Mar 2025 14:20:58 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <2zcaAu3ekLqIiiuGnujHkuJ93H1dpq1q-nUEfFdV7Vo=.ca0aa607-d0bd-43fd-8142-9ea33adb3bff@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

I just verified that this PR does not fix the original issue on the Mac.

Note: I could not reproduce the bug on my Mac 15.3.2 M2 Max using the latest master. Then I went to System Settings > Desktop & Dock and turned on "Minimize windows into application icon". Then the problem reproduced. But when I toggled that switch back off and the bug still reproduced.

This may be irrelevant but I did notice a difference between Mac and Windows. After glass sends notifySize RESTORE it sends notifyRepaint on Windows but not on Mac. In fact I don't think the Mac ever sends notifyRepaint.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2724839679

From angorya at openjdk.org  Fri Mar 14 14:35:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Mar 2025 14:35:03 GMT
Subject: [jfx24] RFR: 8350136: Create release notes for JavaFX 24
In-Reply-To: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
References: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
Message-ID: <uKp4ptROZuujTs1Et3u4iHpcOC9qYTqY-YON97PUTjE=.580cce41-2271-46ed-b1b5-9bbcb737c040@github.com>

On Fri, 14 Mar 2025 13:20:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 24 release notes to the `jfx24` stabilization branch, so they will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx24 will not cause a respin of JavaFX 24.

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1736#pullrequestreview-2685768871

From angorya at openjdk.org  Fri Mar 14 14:45:02 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Mar 2025 14:45:02 GMT
Subject: Integrated: 8351067: Enforce Platform threading use
In-Reply-To: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
References: <j71EU_SiyO9JnEVTvPs9jb8IBRj5EdwIloMDbsXjN-I=.4d0c3f31-e94c-436e-9afe-7f0bf9dd46c3@github.com>
Message-ID: <FlHGiVMp021gIH_MrC7_zeXP6O1jfeA0zspSlwVIjp8=.f02a006f-406e-4468-aa79-3ebe1ad46b0e@github.com>

On Tue, 4 Mar 2025 19:00:06 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Summary
> -------
> 
> Adds a thread check to a number of `Platform` methods:
> 
> accessibilityActiveProperty()
> getPreferences()
> isAccessibilityActive()
> 
> These methods will throw an `IllegalStateException` if called on a thread other than the JavaFX Application Thread.
> 
> Problem
> -------
> 
> JavaFX allows the Nodes and Scenes to be created and modified on any thread as long as they are not yet attached to a `Window` that is showing.
> 
> This is allowed in an implicit assumption that the construction code only modifies the properties of the said Nodes and Scenes, but not other static or global entities.  Concurrent multi-threaded access of such entities not only breaks the initialization of the properties, but also causes the failures down the road, if the change to the global properties happens while the Nodes and Scenes are still being constructed.
> 
> Even JavaFX platform developers did not avoid tripping over this issue, as can be illustrated by https://bugs.openjdk.org/browse/JDK-8348987 . 
> 
> Solution
> --------
> 
> Fail each method fast with an  `IllegalStateException` if called from a background thread.
> 
> While this solution won't prevent other possible abuse, such as getting a reference to the property in the JavaFX Application Thread and later accessing it in a background thread, adding a check and allowing these methods to fail fast should prevent most likely scenarios.

This pull request has now been integrated.

Changeset: a87f0a55
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a87f0a55114e23ba6caeae28be7c910da584b5fa
Stats:     42 lines in 2 files changed: 24 ins; 14 del; 4 mod

8351067: Enforce Platform threading use

Reviewed-by: kcr, mstrauss

-------------

PR: https://git.openjdk.org/jfx/pull/1728

From mfox at openjdk.org  Fri Mar 14 14:52:00 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 14 Mar 2025 14:52:00 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <f4VEdoftskjeJqqAL6ZFxK4RXKAYxEDgfWLyc491Mrk=.6417c32c-1319-4fbe-9cc7-caaf97059207@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

Adding `entireSceneNeedsRepaint` fixes this on the Mac.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2724935929

From kcr at openjdk.org  Fri Mar 14 15:14:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 15:14:07 GMT
Subject: [jfx24] Integrated: 8350136: Create release notes for JavaFX 24
In-Reply-To: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
References: <GTQjAsip58eNO1ahSr8YmJ6thpb3mi9PcNJygcfNfFg=.66844e7a-c794-459f-8947-19185124e661@github.com>
Message-ID: <pj3zuIE-7SsdtKWInr28_sZMq6hzbXmvi7FYyOyXi5k=.de8d447b-a526-4a9e-9c51-ebd6c3221d9b@github.com>

On Fri, 14 Mar 2025 13:20:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean backport of the JavaFX 24 release notes to the `jfx24` stabilization branch, so they will be available in that branch when JavaFX 24 is published (and from there also synced into the jfx24u repo).
> 
> NOTE: The release notes are not part of the build, so this backport to jfx24 will not cause a respin of JavaFX 24.

This pull request has now been integrated.

Changeset: 75f6c99a
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/75f6c99a7744eecb38c57cb2862d2b475caeaccd
Stats:     275 lines in 2 files changed: 275 ins; 0 del; 0 mod

8350136: Create release notes for JavaFX 24

Reviewed-by: angorya
Backport-of: d2ab2c89fcb1dce3c3f1ccb9f031e77cefe6ddbc

-------------

PR: https://git.openjdk.org/jfx/pull/1736

From kcr at openjdk.org  Fri Mar 14 15:21:07 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 15:21:07 GMT
Subject: RFR: 8351653: Webkit debug build failure after update to 620.1
In-Reply-To: <gjLnuFERz_U2hOsLtELF6Fa5xfUXIk_z-6XyXiXsgzs=.51286476-d31f-4800-b0e6-a7ca818c809e@github.com>
References: <gjLnuFERz_U2hOsLtELF6Fa5xfUXIk_z-6XyXiXsgzs=.51286476-d31f-4800-b0e6-a7ca818c809e@github.com>
Message-ID: <u3v2XgEuMFEQkvox6a6pRpkE5RfL1eS8_LaKjjRHt6A=.9de76c84-ae8b-4c57-adcf-39d101921285@github.com>

On Thu, 13 Mar 2025 05:04:00 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> issue : build fails on debug mode. invalid casting
> Solution: the casting should be with char* , need to use SourceUTF8().data()

Looks good. This fixes the debug build on macOS. We already have an older bug, [JDK-8329874](https://bugs.openjdk.org/browse/JDK-8329874), tracking the debug build failures on Windows and Linux.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1732#pullrequestreview-2685899306

From mstrauss at openjdk.org  Fri Mar 14 16:21:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 14 Mar 2025 16:21:22 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v5]
In-Reply-To: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
Message-ID: <GQ8rt666Li5q9xmhvwS28fDhzcpIPBmLfkwKAd7hZkg=.29709201-e8a2-43a0-ab5f-f6fa564e4ed2@github.com>

> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  rename system property

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1359/files
  - new: https://git.openjdk.org/jfx/pull/1359/files/8ed78967..cffad4ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1359.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359

PR: https://git.openjdk.org/jfx/pull/1359

From angorya at openjdk.org  Fri Mar 14 16:32:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Mar 2025 16:32:11 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v5]
In-Reply-To: <GQ8rt666Li5q9xmhvwS28fDhzcpIPBmLfkwKAd7hZkg=.29709201-e8a2-43a0-ab5f-f6fa564e4ed2@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <GQ8rt666Li5q9xmhvwS28fDhzcpIPBmLfkwKAd7hZkg=.29709201-e8a2-43a0-ab5f-f6fa564e4ed2@github.com>
Message-ID: <umWzlHfO2gJ5T2tV8wBkjsI832lJ_JbzUDTCoMwZOLg=.135f70ad-f858-4165-83ad-eb2596e82f54@github.com>

On Fri, 14 Mar 2025 16:21:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename system property

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2686118875

From snazarki at openjdk.org  Fri Mar 14 17:21:00 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 14 Mar 2025 17:21:00 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <bZX28J6RaggptxIXD1heEyXS65nXA0uBXN_RilYLUlA=.4aee5a5d-4075-4c0f-89b9-0d6717eef2fc@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
 <bZX28J6RaggptxIXD1heEyXS65nXA0uBXN_RilYLUlA=.4aee5a5d-4075-4c0f-89b9-0d6717eef2fc@github.com>
Message-ID: <6D8Xq6aT-ib5n1-DpvWynKLqvbZ9mhtxa45yh_qiD5M=.1c38826f-d98e-47cb-9b59-6103a92b3fe0@github.com>

On Fri, 14 Mar 2025 14:12:30 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Hi!
>> 
>> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
>> 
>> #  What is the problem?
>> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
>> Stack trace
>> 
>>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::B...
>
> Initial testing shows that while this does prevent the crash, it doesn't actually render anything in the failing case.
> 
> @jaybhaskar will add more detail on Monday. He and @Gopalora are working on an actual fix.

@kevinrushforth thank you for the review. I expected something like this. BTW, we've just found that win32 and osx-x64 crashes even with this fix.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1734#issuecomment-2725303486

From mfox at openjdk.org  Fri Mar 14 18:39:43 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 14 Mar 2025 18:39:43 GMT
Subject: RFR: 8091629: [Mac] Support the automatic hiding of the "java" menu
 bar item when using the system menu bar
Message-ID: <s-jTHkFqArugvHW26K7wloPJaR33iB1rtWZOOTxEqLE=.bc5ff723-7151-40ed-a04d-0aa7a9a856e2@github.com>

On the Mac the application menu (the one to the right of the Apple logo menu) is created by JavaFX and there is no public API to customize or localize it. This PR allows a client to get rid of it and replace it with an entirely custom JavaFX Menu.

Prior to OS X 10.6 (Snow Leopard) the application menu required special handling. Nowadays it's just the first item in the NSApp's mainMenu. The only restriction is that the OS ignores the item's title and instead uses the application's name as specified in the CFBundle.

This PR is a work-in-progress/trial balloon. It provides a new property on the MenuBar that controls whether the system will use the default menus. It also supplies the calls necessary to implement the standard menu items "Hide <application>", "Hide Others", and "Show All" which need to be routed to native calls on the NSApplication object. A manual test app is available in tests/manual/controls/DefaultAppMenu.java.

-------------

Commit messages:
 - Added stub TKSystemMenu routines
 - Fixed javadoc issue
 - Added manual test app
 - Added calls necessary to reproduce the Mac application menu.
 - Provide property to disable default menus in the system menu bar

Changes: https://git.openjdk.org/jfx/pull/1737/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1737&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8091629
  Stats: 417 lines in 11 files changed: 399 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jfx/pull/1737.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1737/head:pull/1737

PR: https://git.openjdk.org/jfx/pull/1737

From kcr at openjdk.org  Fri Mar 14 21:05:01 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 21:05:01 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v5]
In-Reply-To: <GQ8rt666Li5q9xmhvwS28fDhzcpIPBmLfkwKAd7hZkg=.29709201-e8a2-43a0-ab5f-f6fa564e4ed2@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <GQ8rt666Li5q9xmhvwS28fDhzcpIPBmLfkwKAd7hZkg=.29709201-e8a2-43a0-ab5f-f6fa564e4ed2@github.com>
Message-ID: <PJPCLTXjBN1wFziE3ujUcmuhNJY1z2b4Om1poFWsXIg=.b94a55a4-319e-4fc1-8da0-62b727d56184@github.com>

On Fri, 14 Mar 2025 16:21:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename system property

I note one more place (in the docs for an internal method) where it still says "Banner".

modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 59:

> 57:      * Verifies that preview features are enabled, and throws an exception otherwise.
> 58:      * <p>
> 59:      * Unless suppressed with the {@code javafx.suppressPreviewBanner=true} system property, this method

Banner --> Warning

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2686822170
PR Review Comment: https://git.openjdk.org/jfx/pull/1359#discussion_r1996277124

From kcr at openjdk.org  Fri Mar 14 21:34:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 14 Mar 2025 21:34:59 GMT
Subject: RFR: 8091629: [Mac] Support the automatic hiding of the "java"
 menu bar item when using the system menu bar
In-Reply-To: <s-jTHkFqArugvHW26K7wloPJaR33iB1rtWZOOTxEqLE=.bc5ff723-7151-40ed-a04d-0aa7a9a856e2@github.com>
References: <s-jTHkFqArugvHW26K7wloPJaR33iB1rtWZOOTxEqLE=.bc5ff723-7151-40ed-a04d-0aa7a9a856e2@github.com>
Message-ID: <LPXCmhB4nyRgFHrCx8q8OC4Vrc-rmWNyjIS__bnW458=.e9b46389-47c9-4413-8967-cbb4c78dc5c2@github.com>

On Fri, 14 Mar 2025 18:09:23 GMT, Martin Fox <mfox at openjdk.org> wrote:

> On the Mac the application menu (the one to the right of the Apple logo menu) is created by JavaFX and there is no public API to customize or localize it. This PR allows a client to get rid of it and replace it with an entirely custom JavaFX Menu.
> 
> Prior to OS X 10.6 (Snow Leopard) the application menu required special handling. Nowadays it's just the first item in the NSApp's mainMenu. The only restriction is that the OS ignores the item's title and instead uses the application's name as specified in the CFBundle.
> 
> This PR is a work-in-progress/trial balloon. It provides a new property on the MenuBar that controls whether the system will use the default menus. It also supplies the calls necessary to implement the standard menu items "Hide <application>", "Hide Others", and "Show All" which need to be routed to native calls on the NSApplication object. A manual test app is available in tests/manual/controls/DefaultAppMenu.java.

This should be discussed on the mailing list first. I recommend moving it to Draft for now. If it goes forward it will need a CSR.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1737#issuecomment-2725820152

From angorya at openjdk.org  Fri Mar 14 22:53:36 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 14 Mar 2025 22:53:36 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v2]
In-Reply-To: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
Message-ID: <yI7AHMnz1Dx71tPCk5mgyp6efxH2E6L_tbvFpeY2VdQ=.994cab96-1d84-4b94-b61d-d2c6dbbf3621@github.com>

> Fixed two issues found in importing RTF text:
> 
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
> 
> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?

Andy Goryachev has updated the pull request incrementally with four additional commits since the last revision:

 - whitespace
 - test
 - strikethrough
 - missing code in attr set

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1735/files
  - new: https://git.openjdk.org/jfx/pull/1735/files/5c4285ec..894ee93e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=00-01

  Stats: 162 lines in 2 files changed: 158 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1735/head:pull/1735

PR: https://git.openjdk.org/jfx/pull/1735

From jbhaskar at openjdk.org  Sat Mar 15 02:27:03 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 15 Mar 2025 02:27:03 GMT
Subject: Integrated: 8351653: Webkit debug build failure after update to 620.1
In-Reply-To: <gjLnuFERz_U2hOsLtELF6Fa5xfUXIk_z-6XyXiXsgzs=.51286476-d31f-4800-b0e6-a7ca818c809e@github.com>
References: <gjLnuFERz_U2hOsLtELF6Fa5xfUXIk_z-6XyXiXsgzs=.51286476-d31f-4800-b0e6-a7ca818c809e@github.com>
Message-ID: <BEW2zg-jeENyg4t-asqPd4CmlnUcc0f9wwDHumOT0IA=.b73cbeb7-44e2-4f31-97f1-5285178918f2@github.com>

On Thu, 13 Mar 2025 05:04:00 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> issue : build fails on debug mode. invalid casting
> Solution: the casting should be with char* , need to use SourceUTF8().data()

This pull request has now been integrated.

Changeset: 99ee34fe
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/99ee34fe6f82dddc554a32d09e88b9e43329045e
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8351653: Webkit debug build failure after update to 620.1

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1732

From jbhaskar at openjdk.org  Sat Mar 15 02:39:59 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 15 Mar 2025 02:39:59 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
Message-ID: <dMR6Rzgchw0vmlbYg9E2IUCpRXsKbT2pGFiseMmhcnc=.ba403619-b3ae-4e6e-8a31-c36076513e38@github.com>

On Thu, 13 Mar 2025 18:17:53 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
> 
> #  What is the problem?
> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
> Stack trace
> 
>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000...

I would like to revisit this once the underlying bug pattern issue has been resolved.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1734#issuecomment-2726139515

From mstrauss at openjdk.org  Sat Mar 15 03:41:29 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 15 Mar 2025 03:41:29 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v6]
In-Reply-To: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
Message-ID: <g9Ep2T9-xfc7xPMeqBqcz4_FQXO4ZB6O9PU7lXce_7A=.70f52062-e669-4470-8573-c12efb381523@github.com>

> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  banner -> warning

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1359/files
  - new: https://git.openjdk.org/jfx/pull/1359/files/cffad4ae..2eb715b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1359&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1359.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1359/head:pull/1359

PR: https://git.openjdk.org/jfx/pull/1359

From kcr at openjdk.org  Sat Mar 15 11:56:59 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 15 Mar 2025 11:56:59 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v6]
In-Reply-To: <g9Ep2T9-xfc7xPMeqBqcz4_FQXO4ZB6O9PU7lXce_7A=.70f52062-e669-4470-8573-c12efb381523@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <g9Ep2T9-xfc7xPMeqBqcz4_FQXO4ZB6O9PU7lXce_7A=.70f52062-e669-4470-8573-c12efb381523@github.com>
Message-ID: <l750fKH7KL46ANnqAsCi5G_u08_qmRuAilsl8zQ-7_Q=.32a21b41-c524-4071-a5d4-57c182bf298d@github.com>

On Sat, 15 Mar 2025 03:41:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   banner -> warning

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2687664475

From martinfox656 at gmail.com  Sat Mar 15 19:34:31 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Sat, 15 Mar 2025 12:34:31 -0700
Subject: Removing the default application menu on the Mac
Message-ID: <64496A53-B55D-4A48-A7E4-0B4149402596@gmail.com>

On the Mac the JavaFX core creates the application menu, the one immediately adjacent to the Apple menu in the menu bar. There is no JavaFX API to access it so a developer can?t localize the existing items or add additional ones (like About). We can?t easily provide access to it since it?s not built using public Controls. While thinking about how to fix this I realized the simplest approach would be to just remove it entirely and let the developer build their own.

Before macOS Snow Leopard (10.6, circa 2009) the application menu was created by the OS and you had to issue special calls to replace it. Now it?s simply the first item in the NSApplication?s mainMenu. If the system menu bar is enabled removing the built-in application menu simply shifts the JavaFX MenuBar menus over so the first menu becomes the application menu.

Unfortunately we would need to fill some holes in the JavaFX API to make this a useful solution. Currently the system tears down the system menu bar when a Stage is iconified and there?s no way to specify a menu bar to be displayed when there?s no Stage. There should be an API that allows a developer to provide a default menu bar to display in these situations. Any suggestions on what that would look like are welcome.

I pulled together a rough draft as a proof of concept (https://git.openjdk.org/jfx/pull/1737). It adds a new property to the MenuBar that allows the developer to shut off the default application menu. It also provides the calls necessary to implement the standard Hide, Hide Others, and Show All items that usually appear in the app menu.

Let me know if you have any thoughts or feedback.

Martin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250315/d1268889/attachment.htm>

From crschnick at xpipe.io  Sun Mar 16 08:25:25 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sun, 16 Mar 2025 09:25:25 +0100
Subject: Resizing stage while it is maximized breaks scene size on Linux
Message-ID: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>

Hello,

we encountered an issue on Linux where resizing the stage while it is 
maximized breaks the size of the scene. You can see a video of this at 
https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that 
the stage size is modified.

When doing this, it temporarily or permanently switches to the size the 
stage had prior to being maximized, leading to either a flicker or a 
permanently broken scene that has the wrong size. This happens on Gnome 
and KDE for me with the latest JavaFX ea version.

Here is a simple reproducer:

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.Region;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

import java.io.IOException;
import java.util.Base64;

public class MaximizeLinuxBugextends Application {

     @Override public void start(Stage stage)throws IOException {
         Scene scene =new Scene(createContent(),640,480);
         var s ="data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
         scene.getStylesheets().add(s);
         stage.setTitle("Hello!");
         stage.setScene(scene);
         stage.show();
         stage.centerOnScreen();
         stage.setMaximized(true);
     }

     private StringcreateCss() {
         return """ * { -fx-border-color: red; -fx-border-width: 1; } """;
     }

     private RegioncreateContent() {
         var button =new Button("Click me!");
         button.setOnAction(event -> {
             var w =button.getScene().getWindow();
             w.setWidth(w.getWidth() -1);
             event.consume();
         });
         var stack =new StackPane(button);
         return stack;
     }

     public static void main(String[] args) {
         launch();
     }
}


Best
Christopher Schnick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250316/32b4e3c2/attachment.htm>

From mstrauss at openjdk.org  Sun Mar 16 09:13:03 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 16 Mar 2025 09:13:03 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <Ieb_X7SRc5_KUnwT_LCZlJoU_P9eJIxtF8FFmIQwi_I=.2ab842aa-413d-4243-9ab4-2b32b191c9a2@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <Ieb_X7SRc5_KUnwT_LCZlJoU_P9eJIxtF8FFmIQwi_I=.2ab842aa-413d-4243-9ab4-2b32b191c9a2@github.com>
Message-ID: <vB89NAhNgUAMbiGRorN4Q-vC3hJTmS0PnAmysgQ8KRg=.7292d909-b917-4b61-ad96-b7e6d226b516@github.com>

On Thu, 13 Mar 2025 17:36:35 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 739:
> 
>> 737:             s = s.replace("\n", "");
>> 738:             return s;
>> 739:         }, getSkinnable().promptTextProperty()));
> 
> two minor problems:
> 1. missing { } after `if`.  (I would highly recommend always using { })
> 2. when s is null you call replace() unnecessarily
> 
> suggestion:
> 
>             String s = getSkinnable().getPromptText();
>             if (s == null) {
>                 return "";
>             }
>             return s.replace("\n", "");

You should consider using a fluent binding here, which is a more modern solution compared to the `Bindings` class. It is also simpler because you don't need to check for `null`:


promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r1997537410

From mstrauss at openjdk.org  Sun Mar 16 09:17:58 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 16 Mar 2025 09:17:58 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <y-QsBIMqeoT8GRcuM6Ilp1r5g5IP3kSg_bKvBBaGs3U=.d95aff2d-b9fb-41c9-bd9c-bb39624b7c2f@github.com>

On Wed, 19 Feb 2025 16:50:02 GMT, Ziad El Midaoui <duke at openjdk.org> wrote:

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

What happens if the text contains line breaks other than `\n`, such as `\r` or `\r\n`? There's `System.lineSeparator()`, but we might want to remove all kinds of line separators regardless.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2727285120

From mstrauss at openjdk.org  Sun Mar 16 19:11:02 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 16 Mar 2025 19:11:02 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

modules/javafx.graphics/src/main/java/javafx/css/Styleable.java line 101:

> 99:      * only for its direct children!
> 100:      *
> 101:      * @return an immutable list of CSS meta data, never {@code null}

Since we don't specify that `getCssMetaData()` should never return null, we should consider also not specifying it here. Alternatively, maybe we should add the non-null requirement to the existing `getCssMetaData()`.

modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 465:

> 463:     }
> 464: 
> 465:     private record StylingContext(Node node, CalculatedValue font, StyleMap styleMap, Set<PseudoClass> pseudoClasses) {}

It might not be a good trade-off to create lots of transient objects on a hot path just to save a few arguments in the calling convention. This would be a nice improvement once we have value types in Java.

modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java line 128:

> 126:         @SuppressWarnings("unchecked")
> 127:         StyleableObjectProperty<T> castProperty = (StyleableObjectProperty<T>) child.getProperties()
> 128:             .computeIfAbsent(cssMetaData, k -> createChildConstraintProperty(child, cssMetaData));

Since we're on a hot path here, I'd like to see this work without unnecessary memory allocations:
1. Check `hasProperties()` before calling `getProperties()`.
2. Don't use `computeIfAbsent()` since it requires a capturing lambda.

modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java line 140:

> 138:         }
> 139: 
> 140:         String propertyName = name + " (parent property)";

I think a more sensible naming scheme would be something like "VBox.margin", which should be supplied as an argument and not generated on the fly.

modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java line 234:

> 232:             }
> 233: 
> 234:             if (value != null) {

How would the value ever be anything other than a `StyleableObjectProperty`, since `setChildConstraint()` always creates a `StyleableObjectProperty`?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997679699
PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997663655
PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997683419
PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997682667
PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997684595

From jhendrikx at openjdk.org  Sun Mar 16 21:29:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 16 Mar 2025 21:29:01 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
Message-ID: <MhJnbCnA8pemQV21BKb7GdpQOhz_0bR1YRCoPDzJqQ8=.774b9231-b9e2-4f61-aa39-4fcdee7acfd9@github.com>

On Sun, 16 Mar 2025 17:08:31 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes
>
> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 465:
> 
>> 463:     }
>> 464: 
>> 465:     private record StylingContext(Node node, CalculatedValue font, StyleMap styleMap, Set<PseudoClass> pseudoClasses) {}
> 
> It might not be a good trade-off to create lots of transient objects on a hot path just to save a few arguments in the calling convention. This would be a nice improvement once we have value types in Java.

I checked this before hand, there is quite a bit more going on in creating the cache keys (see `getTransitionStates`), and I think this extra object will therefore be lost in the noise.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997717173

From jhendrikx at openjdk.org  Sun Mar 16 21:32:00 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 16 Mar 2025 21:32:00 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
Message-ID: <_bQ1pwrSW2UdNnfgv2DGuNJqEUddCWKvMacdI7D693o=.daf886e9-891f-4b77-8a5d-d11f19eefb06@github.com>

On Sun, 16 Mar 2025 18:36:05 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes
>
> modules/javafx.graphics/src/main/java/javafx/css/Styleable.java line 101:
> 
>> 99:      * only for its direct children!
>> 100:      *
>> 101:      * @return an immutable list of CSS meta data, never {@code null}
> 
> Since we don't specify that `getCssMetaData()` should never return null, we should consider also not specifying it here. Alternatively, maybe we should add the non-null requirement to the existing `getCssMetaData()`.

That might be a good idea, as there are several places in `CssStyleHelper` where `getCssMetaData` is assumed to be non-null already (and also a few locations where it is assumed it can be `null`).  In other words, if the function would return `null`, FX would break currently.

For example, `recalculateRelativeSizeProperties` will do:

        final List<CssMetaData<? extends Styleable,  ?>> styleables = node.getCssMetaData();
        final int numStyleables = styleables.size();
        
Which would be an NPE.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997723358

From jhendrikx at openjdk.org  Sun Mar 16 21:36:01 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 16 Mar 2025 21:36:01 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
Message-ID: <8fxWEMmHux_crHE7EXNytDmr_CmKTsEWlCNGaO0E_Zk=.d35857e9-2db3-48a6-a635-6e1f0dc64859@github.com>

On Sun, 16 Mar 2025 18:53:41 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java line 140:
> 
>> 138:         }
>> 139: 
>> 140:         String propertyName = name + " (parent property)";
> 
> I think a more sensible naming scheme would be something like "VBox.margin", which should be supplied as an argument and not generated on the fly.

I can change that to whatever you like.  Be aware this is only for the `toString` (both `getBean` and `getName` are optional methods to implement).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997724336

From jhendrikx at openjdk.org  Sun Mar 16 21:45:58 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sun, 16 Mar 2025 21:45:58 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
Message-ID: <qkUqWZOzSVUXwBZ2aKfIOx3r8vpKLbRi5YiJFDbBQo0=.0b7e48e1-a1b1-4c5b-a52d-474078afb4de@github.com>

On Sun, 16 Mar 2025 19:03:32 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Pane.java line 234:
> 
>> 232:             }
>> 233: 
>> 234:             if (value != null) {
> 
> How would the value ever be anything other than a `StyleableObjectProperty`, since `setChildConstraint()` always creates a `StyleableObjectProperty`?

Yeah, this is not handled well. It was intended to mimic a standard value with the property being created (like the lazy property pattern), but it doesn't work here.

In theory, as the property map is public, one could set the key to something else (not easily mind you, you'd need to iterate to find the keys as they're no longer predictable `String`s).  So, I'll remove this code, and just ignore any bad value and proceed with returning the default value.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1997731065

From mstrauss at openjdk.org  Mon Mar 17 06:28:59 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Mar 2025 06:28:59 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <_bQ1pwrSW2UdNnfgv2DGuNJqEUddCWKvMacdI7D693o=.daf886e9-891f-4b77-8a5d-d11f19eefb06@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <c06-pQcS9LNGc4odlsrmuhKT_LhYrUGgcmrceavuaBU=.8d3b2aae-5de8-4d6f-92bb-5c9fb2a48985@github.com>
 <_bQ1pwrSW2UdNnfgv2DGuNJqEUddCWKvMacdI7D693o=.daf886e9-891f-4b77-8a5d-d11f19eefb06@github.com>
Message-ID: <R6NFRXm1jMyOzBUp_yC7CT2rEqnJviJd1XqZX0-ODkE=.7f39180e-63fa-4250-8316-6c434477c166@github.com>

On Sun, 16 Mar 2025 21:29:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/css/Styleable.java line 101:
>> 
>>> 99:      * only for its direct children!
>>> 100:      *
>>> 101:      * @return an immutable list of CSS meta data, never {@code null}
>> 
>> Since we don't specify that `getCssMetaData()` should never return null, we should consider also not specifying it here. Alternatively, maybe we should add the non-null requirement to the existing `getCssMetaData()`.
>
> That might be a good idea, as there are several places in `CssStyleHelper` where `getCssMetaData` is assumed to be non-null already (and also a few locations where it is assumed it can be `null`).  In other words, if the function would return `null`, FX would break currently.
> 
> For example, `recalculateRelativeSizeProperties` will do:
> 
>         final List<CssMetaData<? extends Styleable,  ?>> styleables = node.getCssMetaData();
>         final int numStyleables = styleables.size();
>         
> Which would be an NPE.

I think then you can do this as part of this PR, since you?re already touching the `Styleable` interface.

>> modules/javafx.graphics/src/main/java/javafx/scene/CssStyleHelper.java line 465:
>> 
>>> 463:     }
>>> 464: 
>>> 465:     private record StylingContext(Node node, CalculatedValue font, StyleMap styleMap, Set<PseudoClass> pseudoClasses) {}
>> 
>> It might not be a good trade-off to create lots of transient objects on a hot path just to save a few arguments in the calling convention. This would be a nice improvement once we have value types in Java.
>
> I checked this before hand, there is quite a bit more going on in creating the cache keys (see `getTransitionStates`), and I think this extra object will therefore be lost in the noise.

I still think that it doesn?t carry its weight (bundling up private method arguments in the same translation unit is not a big win). It will increase churn on the GC, even if slightly, and many of these decisions taken together may cause it to run more often or earlier.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1998018887
PR Review Comment: https://git.openjdk.org/jfx/pull/1714#discussion_r1998016829

From mstrauss at openjdk.org  Mon Mar 17 06:32:09 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Mar 2025 06:32:09 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
Message-ID: <zvwSISdCW2DBRHz4qqDeWrTRHxYtNQsDnSapt3VjBvQ=.2e685d16-1513-4485-9d95-ccb7ee4dce71@github.com>

On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> 8350917: Allow parent nodes to provide CSS styleable properties for child nodes

Your approach for this enhancement looks good. Do you plan to add styleable properties for the other layout containers too?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2728323145

From jbhaskar at openjdk.org  Mon Mar 17 06:42:26 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 17 Mar 2025 06:42:26 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
Message-ID: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>

Issue: Some images don't load with WebKit 620.1

WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.

Solution:
Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

-------------

Commit messages:
 - 8351264: Some images don't load with WebKit 620.1

Changes: https://git.openjdk.org/jfx/pull/1738/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1738&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351264
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1738.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1738/head:pull/1738

PR: https://git.openjdk.org/jfx/pull/1738

From jhendrikx at openjdk.org  Mon Mar 17 09:22:14 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 17 Mar 2025 09:22:14 GMT
Subject: RFR: 8350917: Allow parent nodes to provide CSS styleable
 properties for child nodes
In-Reply-To: <zvwSISdCW2DBRHz4qqDeWrTRHxYtNQsDnSapt3VjBvQ=.2e685d16-1513-4485-9d95-ccb7ee4dce71@github.com>
References: <1zUL0IZDt34EwVcBrNUoPJjky73ZVwlJM9q5ZK5lw18=.0209a28b-cef4-4769-9e0d-f0a01907167e@github.com>
 <zvwSISdCW2DBRHz4qqDeWrTRHxYtNQsDnSapt3VjBvQ=.2e685d16-1513-4485-9d95-ccb7ee4dce71@github.com>
Message-ID: <w_o-JbehR61Vuyr__RM6DV56gy52Lgf1C6raAuh1Giw=.7779dc1a-1ba5-4811-a63d-72cf9840b9c4@github.com>

On Mon, 17 Mar 2025 06:29:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Your approach for this enhancement looks good. Do you plan to add styleable properties for the other layout containers too?

I would like to, I was thinking of doing that in a separate PR as there are quite a few (and I think they would need documentation as well).  I think there's `GridPane`, `StackPane`, `AnchorPane`, `TilePane` and `BorderPane` as well.  It might speed along reviews to keep the PR's smaller.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1714#issuecomment-2728729187

From thiago.sayao at gmail.com  Mon Mar 17 09:53:55 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Mon, 17 Mar 2025 06:53:55 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
Message-ID: <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>

Hi Christopher,

It seems like a simple fix.

How does it behave on other platforms? Does it ignore the resize, restore
the window to its unmaximized state before resizing, or keep it maximized
while adjusting the unmaximized size.

-- Thiago






Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick <
crschnick at xpipe.io> escreveu:

> Hello,
>
> we encountered an issue on Linux where resizing the stage while it is
> maximized breaks the size of the scene. You can see a video of this at
> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that the
> stage size is modified.
>
> When doing this, it temporarily or permanently switches to the size the
> stage had prior to being maximized, leading to either a flicker or a
> permanently broken scene that has the wrong size. This happens on Gnome and
> KDE for me with the latest JavaFX ea version.
>
> Here is a simple reproducer:
>
> import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.Region;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
> import java.io.IOException;import java.util.Base64;
> public class MaximizeLinuxBug extends Application {
>
>     @Override    public void start(Stage stage) throws IOException {
>         Scene scene = new Scene(createContent(), 640, 480);
>         var s = "data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>         scene.getStylesheets().add(s);
>         stage.setTitle("Hello!");
>         stage.setScene(scene);
>         stage.show();
>         stage.centerOnScreen();
>         stage.setMaximized(true);
>     }
>
>     private String createCss() {
>         return """                * {                -fx-border-color: red;                -fx-border-width: 1;                }                """;
>     }
>
>     private Region createContent() {
>         var button = new Button("Click me!");
>         button.setOnAction(event -> {
>             var w = button.getScene().getWindow();
>             w.setWidth(w.getWidth() - 1);
>             event.consume();
>         });
>         var stack = new StackPane(button);
>         return stack;
>     }
>
>     public static void main(String[] args) {
>         launch();
>     }
> }
>
>
> Best
> Christopher Schnick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250317/e4110a3d/attachment-0001.htm>

From crschnick at xpipe.io  Mon Mar 17 12:48:57 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 17 Mar 2025 13:48:57 +0100
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
Message-ID: <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>

So on Windows at least, it will change the width temporarily and then 
revert back to the original width value. So you will receive two width 
change events if you listen to the stage width property. The maximized 
property is not changed.

I guess this also not optimal handling of this. Ideally, no changes 
would be made in that case.

On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
> Hi Christopher,
>
> It seems like a simple fix.
>
> How does it behave on other platforms? Does it ignore the resize, 
> restore the window to its unmaximized state before resizing, or keep 
> it maximized while adjusting the unmaximized size.
>
> -- Thiago
>
>
>
>
>
>
> Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick 
> <crschnick at xpipe.io> escreveu:
>
>     Hello,
>
>     we encountered an issue on Linux where resizing the stage while it
>     is maximized breaks the size of the scene. You can see a video of
>     this at https://github.com/xpipe-io/xpipe/issues/485 . The root
>     cause is that the stage size is modified.
>
>     When doing this, it temporarily or permanently switches to the
>     size the stage had prior to being maximized, leading to either a
>     flicker or a permanently broken scene that has the wrong size.
>     This happens on Gnome and KDE for me with the latest JavaFX ea
>     version.
>
>     Here is a simple reproducer:
>
>     import javafx.application.Application;
>     import javafx.scene.Scene;
>     import javafx.scene.control.Button;
>     import javafx.scene.layout.Region;
>     import javafx.scene.layout.StackPane;
>     import javafx.stage.Stage;
>
>     import java.io.IOException;
>     import java.util.Base64;
>
>     public class MaximizeLinuxBugextends Application {
>
>          @Override public void start(Stage stage)throws IOException {
>              Scene scene =new Scene(createContent(),640,480);
>              var s ="data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>              scene.getStylesheets().add(s);
>              stage.setTitle("Hello!");
>              stage.setScene(scene);
>              stage.show();
>              stage.centerOnScreen();
>              stage.setMaximized(true);
>          }
>
>          private StringcreateCss() {
>              return """ * { -fx-border-color: red; -fx-border-width: 1; } """;
>          }
>
>          private RegioncreateContent() {
>              var button =new Button("Click me!");
>              button.setOnAction(event -> {
>                  var w =button.getScene().getWindow();
>                  w.setWidth(w.getWidth() -1);
>                  event.consume();
>              });
>              var stack =new StackPane(button);
>              return stack;
>          }
>
>          public static void main(String[] args) {
>              launch();
>          }
>     }
>
>
>     Best
>     Christopher Schnick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250317/f3d3ded9/attachment.htm>

From kcr at openjdk.org  Mon Mar 17 13:25:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Mar 2025 13:25:03 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <h428DDc_MG-LxjQbDlE1eixGJR6S_V7DzO_E9hd3frs=.52925901-b583-4cc3-84df-b1f16e05f45a@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

Reviewers: @jperedadnr @kevinrushforth

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1738#issuecomment-2729490503

From angorya at openjdk.org  Mon Mar 17 14:31:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 14:31:01 GMT
Subject: RFR: 8349373: Support JavaFX preview features [v6]
In-Reply-To: <g9Ep2T9-xfc7xPMeqBqcz4_FQXO4ZB6O9PU7lXce_7A=.70f52062-e669-4470-8573-c12efb381523@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
 <g9Ep2T9-xfc7xPMeqBqcz4_FQXO4ZB6O9PU7lXce_7A=.70f52062-e669-4470-8573-c12efb381523@github.com>
Message-ID: <rBTm6mu5UppWZeVpnvtI3YmzJT92pehK7KYzQPsinaE=.38c64c2c-65f7-487b-afd0-93b8665679be@github.com>

On Sat, 15 Mar 2025 03:41:29 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   banner -> warning

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1359#pullrequestreview-2690745635

From kcr at openjdk.org  Mon Mar 17 15:06:03 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Mar 2025 15:06:03 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <MuR8xhWt2QddqsokLWpQ8dug5yBplmTOIAEwFOgrLuY=.6a63a10a-1fa1-4e67-abd7-5bb59c3780c5@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

This looks good and is a safe fix. I verified that it fixes the problem.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1738#pullrequestreview-2690916447

From jpereda at openjdk.org  Mon Mar 17 15:06:04 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 17 Mar 2025 15:06:04 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <cDhGPzYhpJcGg9oqokrvHLvS7B4VzSlhg8h7aYvlJX8=.afe7322d-6e8c-4671-a58f-fae45b9a45cd@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

I've built and tested on macOS the SDK with this PR, and it works fine now for the reported cases that were failing.

modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequest.cpp line 151:

> 149:         StringBuilder builder;
> 150: // Java platform failing to decode webp image data already disabled in 619.1
> 151: #if (HAVE(WEBP) || USE(WEBP)) && !PLATFORM(JAVA)

I see that 619.1 indeed had:

#if HAVE(WEBP) || USE(WEBP)
         builder.append("image/webp,"_s);
#endif

I wonder why the condition `!PLATFORM(JAVA)` is also required now?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1738#pullrequestreview-2690569143
PR Review Comment: https://git.openjdk.org/jfx/pull/1738#discussion_r1998766992

From kcr at openjdk.org  Mon Mar 17 15:13:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Mar 2025 15:13:00 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <WPht98y5bFjMzgKYp2fegWub6ut89P0l2rxW_fxppzQ=.2fc8e7de-8751-4d8e-b5a0-56d759f75008@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

@jaybhaskar My testing shows that this also fixes the problem loading preview images on the US yahoo.com page, tracked by [JDK-8349561](https://bugs.openjdk.org/browse/JDK-8349561). If this can be confirmed, then [JDK-8349561](https://bugs.openjdk.org/browse/JDK-8349561) should be closed as a duplicate of [JDK-8351264](https://bugs.openjdk.org/browse/JDK-8351264).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1738#issuecomment-2729896693

From kcr at openjdk.org  Mon Mar 17 15:13:02 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Mar 2025 15:13:02 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <cDhGPzYhpJcGg9oqokrvHLvS7B4VzSlhg8h7aYvlJX8=.afe7322d-6e8c-4671-a58f-fae45b9a45cd@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
 <cDhGPzYhpJcGg9oqokrvHLvS7B4VzSlhg8h7aYvlJX8=.afe7322d-6e8c-4671-a58f-fae45b9a45cd@github.com>
Message-ID: <A6H3IJsVoOxgRrdreYbvISO695FbyJG_YHNv9KSgQSU=.8b219818-9a43-4c35-8522-1074949497ce@github.com>

On Mon, 17 Mar 2025 13:46:06 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

>> Issue: Some images don't load with WebKit 620.1
>> 
>> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
>> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
>> 
>> Solution:
>> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
>> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.
>
> modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequest.cpp line 151:
> 
>> 149:         StringBuilder builder;
>> 150: // Java platform failing to decode webp image data already disabled in 619.1
>> 151: #if (HAVE(WEBP) || USE(WEBP)) && !PLATFORM(JAVA)
> 
> I see that 619.1 indeed had:
> 
> #if HAVE(WEBP) || USE(WEBP)
>          builder.append("image/webp,"_s);
> #endif
> 
> I wonder why the condition `!PLATFORM(JAVA)` is also required now?

Likely those two flags are now defined (in 620.1), but weren't defined in 619.1. It is therefore safer to add the `!PLATFORM(JAVA)` and in any case any time we modify code from upstream, we should qualify it with a `PLATFORM(JAVA)` check.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1738#discussion_r1998974216

From jbhaskar at openjdk.org  Mon Mar 17 15:19:03 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 17 Mar 2025 15:19:03 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <gzb_P6GxBnwEPqIPLcL3OM2Y_f2O1YUOKILwSuYytDA=.46fd3f3f-28c7-44bf-9498-0649b3eb45ef@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

This fix also fixes Preview images on yahoo.com rendered incorrectly issue , have tested also

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1738#issuecomment-2729914674

From angorya at openjdk.org  Mon Mar 17 15:21:14 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 15:21:14 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
Message-ID: <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>

> Fixed two issues found in importing RTF text:
> 
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
> 
> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  arabic

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1735/files
  - new: https://git.openjdk.org/jfx/pull/1735/files/894ee93e..f7834f61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=01-02

  Stats: 162 lines in 1 file changed: 155 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1735/head:pull/1735

PR: https://git.openjdk.org/jfx/pull/1735

From kcr at openjdk.org  Mon Mar 17 15:38:00 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 17 Mar 2025 15:38:00 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <gzb_P6GxBnwEPqIPLcL3OM2Y_f2O1YUOKILwSuYytDA=.46fd3f3f-28c7-44bf-9498-0649b3eb45ef@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
 <gzb_P6GxBnwEPqIPLcL3OM2Y_f2O1YUOKILwSuYytDA=.46fd3f3f-28c7-44bf-9498-0649b3eb45ef@github.com>
Message-ID: <GI33MtyBDeUnWZ4BjwNpqYrzJf55MJzndKO9WPI4rP8=.49e17e46-a5a1-4c2a-a254-d4180b0b35d1@github.com>

On Mon, 17 Mar 2025 15:15:59 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

>> Issue: Some images don't load with WebKit 620.1
>> 
>> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
>> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
>> 
>> Solution:
>> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
>> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.
>
> This fix also fixes Preview images on yahoo.com rendered incorrectly issue , have tested also

@jaybhaskar Given how localized and safe this fix is, I waive the 24-hour waiting period for this bug. That will let the backports get started sooner, since we will want to get this into the April CPU to avoid a critical regression.

Once @jperedadnr approves the PR, go ahead and integrate this fix.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1738#issuecomment-2729978937

From jpereda at openjdk.org  Mon Mar 17 15:41:03 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 17 Mar 2025 15:41:03 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <A6H3IJsVoOxgRrdreYbvISO695FbyJG_YHNv9KSgQSU=.8b219818-9a43-4c35-8522-1074949497ce@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
 <cDhGPzYhpJcGg9oqokrvHLvS7B4VzSlhg8h7aYvlJX8=.afe7322d-6e8c-4671-a58f-fae45b9a45cd@github.com>
 <A6H3IJsVoOxgRrdreYbvISO695FbyJG_YHNv9KSgQSU=.8b219818-9a43-4c35-8522-1074949497ce@github.com>
Message-ID: <0IkB40Sj29CiI3MVmAbPR_kx890MnxbUw-6FTJVxcTc=.67d2e078-f11c-4314-a11d-f5e5b24683fa@github.com>

On Mon, 17 Mar 2025 15:08:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.web/src/main/native/Source/WebCore/loader/cache/CachedResourceRequest.cpp line 151:
>> 
>>> 149:         StringBuilder builder;
>>> 150: // Java platform failing to decode webp image data already disabled in 619.1
>>> 151: #if (HAVE(WEBP) || USE(WEBP)) && !PLATFORM(JAVA)
>> 
>> I see that 619.1 indeed had:
>> 
>> #if HAVE(WEBP) || USE(WEBP)
>>          builder.append("image/webp,"_s);
>> #endif
>> 
>> I wonder why the condition `!PLATFORM(JAVA)` is also required now?
>
> Likely those two flags are now defined (in 620.1), but weren't defined in 619.1. It is therefore safer to add the `!PLATFORM(JAVA)` and in any case any time we modify code from upstream, we should qualify it with a `PLATFORM(JAVA)` check.

Thanks, that makes sense

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1738#discussion_r1999051786

From jpereda at openjdk.org  Mon Mar 17 15:41:02 2025
From: jpereda at openjdk.org (Jose Pereda)
Date: Mon, 17 Mar 2025 15:41:02 GMT
Subject: RFR: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <7s5x-nepqUH_W9CWhN41RfKk-2el835a2peZQUANii4=.00370e87-a1ea-4576-96c0-8c9811c159af@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

Marked as reviewed by jpereda (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1738#pullrequestreview-2691065667

From jbhaskar at openjdk.org  Mon Mar 17 16:03:12 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 17 Mar 2025 16:03:12 GMT
Subject: Integrated: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
References: <Yzs-rF0H80wK94lp-Sqtnnfjc119uKk2c3mAVBZ73a4=.60cfe6cf-55cc-4ada-9a37-1f725eb2e3d2@github.com>
Message-ID: <5QtB9AsqmnSquQJwe2jPrQ-t4k_hpQg8Yd2B_2bAhLU=.d96b5d6d-774b-4ce4-8382-46aa4c425875@github.com>

On Mon, 17 Mar 2025 06:38:18 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: Some images don't load with WebKit 620.1
> 
> WebKit Image Decoding Failure Due to Unintended WebP Format Delivery
> WebKit encounters image decoding failures when certain servers respond with WebP images instead of the intended JPEG or PNG format. This issue arises due to WebKit's Accept header configuration, which prioritises WebP by default. Consequently, incomplete or malformed WebP data results in decoding errors.
> 
> Solution:
> Keep the image rendering features and supported formats as webkit 619.1 , and accordingly
> update the Accept header to prioritize JPEG/PNG over WebP unless WebP decoding is confirmed stable.

This pull request has now been integrated.

Changeset: c4fa462f
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/c4fa462f1444c69693aab4107b4b6feee7ee4c7c
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8351264: Some images don't load with WebKit 620.1

Reviewed-by: kcr, jpereda

-------------

PR: https://git.openjdk.org/jfx/pull/1738

From angorya at openjdk.org  Mon Mar 17 16:29:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 16:29:59 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
Message-ID: <rSP4Sg4QjfBArm6Lu0y7GuPAdkd3FTMeyJiXcVY37jk=.eafb15d9-a161-4755-9c86-efef20b871a0@github.com>

On Mon, 17 Mar 2025 15:21:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed two issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   arabic

@Ziad-Mid : please take a look at this PR.

Please refer to https://github.com/openjdk/jfx/blob/master/README-code-reviews.md for general guidance.

The areas I would like you to focus on specifically are:
- pasting Arabic from other RTF sources (outlook, other applications?)
- think of any other possible problems or side effects of the proposed change
- verifying the tests fail in the `master` branch and passing with the fix
- anything else you might find suboptimal or unclear

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2730137021

From duke at openjdk.org  Mon Mar 17 16:30:10 2025
From: duke at openjdk.org (Ziad El Midaoui)
Date: Mon, 17 Mar 2025 16:30:10 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <vKY5P7TZRZiIdj1VidS0wm-eQurFWhJ0SSw9_mf_A7g=.05799466-2351-4306-9fd2-ba57de31f708@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <y-QsBIMqeoT8GRcuM6Ilp1r5g5IP3kSg_bKvBBaGs3U=.d95aff2d-b9fb-41c9-bd9c-bb39624b7c2f@github.com>
 <vKY5P7TZRZiIdj1VidS0wm-eQurFWhJ0SSw9_mf_A7g=.05799466-2351-4306-9fd2-ba57de31f708@github.com>
Message-ID: <PRn43fSP_QPbrSQglDvZKN1XhEE3Si8FOZbI9_C34r0=.4eaffe33-964f-4f9c-8ad8-7795e466665d@github.com>

On Mon, 17 Mar 2025 14:58:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> 3. cr \u000d ---

Yes , this approach do not handle all the line Seperators only "\n" , I will change it to handle it all

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2730127082

From angorya at openjdk.org  Mon Mar 17 16:30:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 16:30:11 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <PRn43fSP_QPbrSQglDvZKN1XhEE3Si8FOZbI9_C34r0=.4eaffe33-964f-4f9c-8ad8-7795e466665d@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <y-QsBIMqeoT8GRcuM6Ilp1r5g5IP3kSg_bKvBBaGs3U=.d95aff2d-b9fb-41c9-bd9c-bb39624b7c2f@github.com>
 <vKY5P7TZRZiIdj1VidS0wm-eQurFWhJ0SSw9_mf_A7g=.05799466-2351-4306-9fd2-ba57de31f708@github.com>
 <PRn43fSP_QPbrSQglDvZKN1XhEE3Si8FOZbI9_C34r0=.4eaffe33-964f-4f9c-8ad8-7795e466665d@github.com>
Message-ID: <5CuBo82bHAO4F-VSQMs1xeOycfUy25aJPT7sx9gxBP8=.fc16cc90-acd6-4e53-9efd-c005520ab63f@github.com>

On Mon, 17 Mar 2025 16:23:11 GMT, Ziad El Midaoui <duke at openjdk.org> wrote:

>>> What happens if the text contains line breaks other than `\n`
>> 
>> This is a good question.
>> I guess it depends on what other characters cause line break in JavaFX.
>> Wikipedia (https://en.wikipedia.org/wiki/Newline) specifies a few:
>> 
>> 
>> 1. vert tab \u000b ---
>> 2. form feed \u000c ---
>> 3. cr \u000d ---
>> 4. crlf \u000d\u000a ---
>> 5. lf \u000a ---
>> 6. nel \u0085 ---
>> 7. ls \u2028 ---
>> 8. ps \u2029 ---
>> 
>> 
>> @Ziad-Mid could you investigate please?
>
>> 3. cr \u000d ---
> 
> Yes , this approach do not handle all the line Seperators only "\n" , I will change it to handle it all

@Ziad-Mid please make sure we _need_ to change - does the code (with no filtering) render **other** newline characters?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2730132473

From angorya at openjdk.org  Mon Mar 17 16:55:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 16:55:15 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
Message-ID: <JMpQNDdCDmREBqyspiyDVAZzvWvU55kqISCeuylHm7U=.1023ab49-ac44-478a-b97d-f7e3fb1909b2@github.com>

On Mon, 17 Mar 2025 15:21:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed two issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   arabic

Reviewers: @Ziad-Mid @kevinrushforth

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2730209067

From mstrauss at openjdk.org  Mon Mar 17 17:27:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Mar 2025 17:27:23 GMT
Subject: Integrated: 8349373: Support JavaFX preview features
In-Reply-To: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
References: <V0eWutr26Xg3HmTRSGOFKpYw_fOnsSFmVTD98ExcTYg=.ea58710e-d260-402c-9dc0-25e7733f2197@github.com>
Message-ID: <sVfvCQKvdH_F8OGba7av4KCSHpuu_ILV2T5T12IQSmc=.65540737-9a60-4d3a-a364-50c6c1119133@github.com>

On Wed, 7 Feb 2024 20:05:01 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This PR contains a definition of preview features for JavaFX, as well as a helper class to verify that an application has opted into preview features.

This pull request has now been integrated.

Changeset: f5bdec5a
Author:    Michael Strau? <mstrauss at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/f5bdec5a65a2cf8f6a60c3b6f3a5562dcd67e28f
Stats:     91 lines in 3 files changed: 89 ins; 0 del; 2 mod

8349373: Support JavaFX preview features

Reviewed-by: kcr, angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1359

From mstrauss at openjdk.org  Mon Mar 17 17:47:12 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Mar 2025 17:47:12 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v54]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <ike_UMVP4csKF3gSDFUrxQCRDjm_A9yveKRxy0cfrVU=.f44f956f-3855-4d52-bc65-5d386b5e5c2b@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits:

 - add preview feature
 - Merge branch 'master' into feature/extended-window
 - tweak header button glyph scaling
 - Merge branch 'master' into feature/extended-window
 - remove HeaderButtonOverlay.allowRtl
 - minify button glyphs
 - typo
 - update copyright headers
 - Merge branch 'master' into feature/extended-window
 - Remove HeaderBarBase
 - ... and 60 more: https://git.openjdk.org/jfx/compare/f5bdec5a...0985e9ce

-------------

Changes: https://git.openjdk.org/jfx/pull/1605/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=53
  Stats: 6497 lines in 75 files changed: 5815 ins; 501 del; 181 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From mstrauss at openjdk.org  Mon Mar 17 18:54:27 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 17 Mar 2025 18:54:27 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  enable preview features in tests

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/8a5defde..30eb29b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=55
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=54-55

  Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From angorya at openjdk.org  Mon Mar 17 21:05:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 17 Mar 2025 21:05:23 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
Message-ID: <Uxpw1HTYAbetC5GBsTnyuPnhfph87O5YU7l28qk1RMg=.52c6abbe-5330-46b0-96c9-ac9562a86131@github.com>

On Mon, 17 Mar 2025 18:54:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable preview features in tests

modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 79:

> 77:         if (enabledForTesting) {
> 78:             // do nothing
> 79:         } else if (!enabled) {

`if (!enabledForTesting && !enabled) {` ?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r1999668098

From mstrauss at openjdk.org  Tue Mar 18 05:09:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 18 Mar 2025 05:09:22 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <Uxpw1HTYAbetC5GBsTnyuPnhfph87O5YU7l28qk1RMg=.52c6abbe-5330-46b0-96c9-ac9562a86131@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
 <Uxpw1HTYAbetC5GBsTnyuPnhfph87O5YU7l28qk1RMg=.52c6abbe-5330-46b0-96c9-ac9562a86131@github.com>
Message-ID: <xhD-mlymHUIU1SJabQsY3G4SfkRbr-TVEBSKJS_ADHw=.bbea3095-801b-4a80-bb0a-ee47d4915a1e@github.com>

On Mon, 17 Mar 2025 21:00:42 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   enable preview features in tests
>
> modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 79:
> 
>> 77:         if (enabledForTesting) {
>> 78:             // do nothing
>> 79:         } else if (!enabled) {
> 
> `if (!enabledForTesting && !enabled) {` ?

I would have to surround both branches (if and else), as otherwise the warning will be emitted during tests. That would, however, increase nesting?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2000212445

From jbhaskar at openjdk.org  Tue Mar 18 05:23:28 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 18 Mar 2025 05:23:28 GMT
Subject: [jfx24u] RFR: 8351653: Webkit debug build failure after update to
 620.1
Message-ID: <wkCPQ7UM7mnrYenObrDU29FtEdelZ0igYSjH020ts6o=.f075f577-e59f-42ef-ab7e-eaf6909a8ac2@github.com>

A clean backport to jfx24u. This fixes debug build error on mac platform.

-------------

Commit messages:
 - Backport 99ee34fe6f82dddc554a32d09e88b9e43329045e

Changes: https://git.openjdk.org/jfx24u/pull/13/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=13&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351653
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx24u/pull/13.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/13/head:pull/13

PR: https://git.openjdk.org/jfx24u/pull/13

From jbhaskar at openjdk.org  Tue Mar 18 12:56:52 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 18 Mar 2025 12:56:52 GMT
Subject: [jfx24u] RFR: 8351264: Some images don't load with WebKit 620.1
Message-ID: <WWdM5iAZsZcGAsP-PA6zYwKWVdofWZe8ksofrODIHU8=.a33488bd-9b74-4712-b12d-8c0b8981a121@github.com>

clean backport to jfx24u. The patch fixes image rendering issue on some websites that might have non compatible images for JavaFX Webkit platform.

-------------

Commit messages:
 - Backport c4fa462f1444c69693aab4107b4b6feee7ee4c7c

Changes: https://git.openjdk.org/jfx24u/pull/14/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=14&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351264
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/14.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/14/head:pull/14

PR: https://git.openjdk.org/jfx24u/pull/14

From jbhaskar at openjdk.org  Tue Mar 18 13:13:24 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Tue, 18 Mar 2025 13:13:24 GMT
Subject: [jfx24u] Integrated: 8351264: Some images don't load with WebKit 620.1
In-Reply-To: <WWdM5iAZsZcGAsP-PA6zYwKWVdofWZe8ksofrODIHU8=.a33488bd-9b74-4712-b12d-8c0b8981a121@github.com>
References: <WWdM5iAZsZcGAsP-PA6zYwKWVdofWZe8ksofrODIHU8=.a33488bd-9b74-4712-b12d-8c0b8981a121@github.com>
Message-ID: <3-sUp5bPzdb-Z-xpgYq5flJDxqYiTo7eMK7WdC0xCmw=.506c3f4a-165a-44c3-8081-ad43b4c02231@github.com>

On Tue, 18 Mar 2025 12:50:38 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> clean backport to jfx24u. The patch fixes image rendering issue on some websites that might have non compatible images for JavaFX Webkit platform.

This pull request has now been integrated.

Changeset: e322a042
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/e322a042dfe9781a43ee659c5bd0ada6ca1728f1
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8351264: Some images don't load with WebKit 620.1

Backport-of: c4fa462f1444c69693aab4107b4b6feee7ee4c7c

-------------

PR: https://git.openjdk.org/jfx24u/pull/14

From arapte at openjdk.org  Tue Mar 18 15:04:33 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 18 Mar 2025 15:04:33 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <XPdttsrpzcsHIeQOiL9zXvLrupGgFc2fnEd7Y4O9qec=.1b9cddf0-8b48-4704-8ae9-e600ae04a631@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

This does fix the issue on windows.
The issue on mac seems intermittent even without this change, and stays intermittent with this change.

The change seems to achieve the intended but the trigger check may not be the best way. `updateSceneState` is used when there are any changes with scene properties.
The redraw should be triggered by checking the change in scene graph. This change just triggers irrespective of that.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2733579704

From zelmidaoui at openjdk.org  Tue Mar 18 15:43:15 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 18 Mar 2025 15:43:15 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <jWTE5QH1OJ6lfLnZUNaOVBIz2zG8nBbT7i_AjNXc6Vo=.f658dc59-0cd3-4752-8602-9e999a67dd98@github.com>

On Wed, 19 Feb 2025 16:50:02 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

I did test the mentioned line separators without filtering and the new lines are not rendered as newlines, so there is no need to add filtering for other line separators as they are already handled by default.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2733728218

From arapte at openjdk.org  Tue Mar 18 16:48:13 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 18 Mar 2025 16:48:13 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v2]
In-Reply-To: <QaCCKBZ_tWPQqB2Bxt-NmgldjevpqVmbpEg__Ruv6k0=.6969ba9c-8e41-4e4f-b597-85a1ccec8a5d@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
 <QaCCKBZ_tWPQqB2Bxt-NmgldjevpqVmbpEg__Ruv6k0=.6969ba9c-8e41-4e4f-b597-85a1ccec8a5d@github.com>
Message-ID: <RMxu91kV0kwH0JxAeQ1xYH0kwBwAsZANGAdhQrOAvTQ=.576dfc92-1784-4c69-a773-8846822a823a@github.com>

On Mon, 10 Mar 2025 14:31:33 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - synchronized `EventType::register()` method
>> - simplified internal constructor which is only used for `EventType.ROOT`
>> 
>> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
>> 
>> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - ignored
>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>  - test
>  - synchronized

LGTM, with a minor suggestion.

modules/javafx.base/src/test/java/test/javafx/event/EventTypeConcurrencyTest.java line 47:

> 45:             try {
> 46:                 ArrayList<Callable<Object>> runs = new ArrayList<>(N);
> 47:                 for(int i=0; i<N; i++) {

minor : formatting : `for (int i = 0; i < N; i++) {`

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1729#pullrequestreview-2695383674
PR Review Comment: https://git.openjdk.org/jfx/pull/1729#discussion_r2001499370

From angorya at openjdk.org  Tue Mar 18 16:57:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Mar 2025 16:57:31 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v3]
In-Reply-To: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
Message-ID: <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>

> - synchronized `EventType::register()` method
> - simplified internal constructor which is only used for `EventType.ROOT`
> 
> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
> 
> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - formatting
 - Merge remote-tracking branch 'origin/master' into 8351038.event.type
 - ignored
 - Merge remote-tracking branch 'origin/master' into 8351038.event.type
 - test
 - synchronized

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1729/files
  - new: https://git.openjdk.org/jfx/pull/1729/files/552a645d..f44d3b7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1729&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1729&range=01-02

  Stats: 415 lines in 10 files changed: 391 ins; 14 del; 10 mod
  Patch: https://git.openjdk.org/jfx/pull/1729.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1729/head:pull/1729

PR: https://git.openjdk.org/jfx/pull/1729

From arapte at openjdk.org  Tue Mar 18 17:08:18 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Tue, 18 Mar 2025 17:08:18 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v3]
In-Reply-To: <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
 <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>
Message-ID: <Z03dFZkNWMHvhsod_2wZRMkgB2oEzK-M3HvyvTANKWA=.86590cfc-6c47-44d6-b415-059b692b5f99@github.com>

On Tue, 18 Mar 2025 16:57:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - synchronized `EventType::register()` method
>> - simplified internal constructor which is only used for `EventType.ROOT`
>> 
>> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
>> 
>> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - formatting
>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>  - ignored
>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>  - test
>  - synchronized

Marked as reviewed by arapte (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1729#pullrequestreview-2695456506

From mfox at openjdk.org  Tue Mar 18 20:20:14 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 18 Mar 2025 20:20:14 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
Message-ID: <SE4uuzlk17aZuf_UnifMQzZDaiy8DoWp4Uiss4ixWSk=.7dea4d1d-05a7-4d51-a513-06791dfd19ef@github.com>

On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Adds code to trigger a scene update when a Window is restored
> 
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and https://bugs.openjdk.org/browse/JDK-8146479

At least on the Mac there seems to be a timing issue. If the MIMIMIZE notification is sent before a scheduled draw occurs the drawing code will clear the scene dirty bit but then skip the actual drawing since the window is minimized. But I've also seen cases where drawing completes before MINIMIZE is sent.

When the window is restored notifyRepaint will be called on Windows and Linux which looks like it will call entireSceneNeedsRepaint to set the scene dirty bit (based on my reading of the code). Windows calls notifyRepaint whenever it gets a WM_PAINT event and I've verified that that happens after a window is restored. Looking at the sources it seems that Linux calls notifyRepaint _only_ when a window is restored (!)

Mac never calls notifyRepaint. There's code to call it but given where it's located I don't think it will ever be executed.

It would be nice to get some clarification on when notifyRepaint should be called and get the platforms to behave more consistently.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2734611810

From andy.goryachev at oracle.com  Tue Mar 18 21:22:52 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 18 Mar 2025 21:22:52 +0000
Subject: Caution: upgrading to Eclipse 2025.03 
Message-ID: <BYAPR10MB30135A02CDA41E33FA1D0614E5DE2@BYAPR10MB3013.namprd10.prod.outlook.com>

Hi,

Just a friendly warning: the latest Eclipse has a compiler bug that triggers two warnings in OpenJFX [0].  The bug is already fixed in one of the nightly builds.

-andy

[0] https://github.com/eclipse-platform/eclipse.platform/issues/1779


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250318/a978ed15/attachment.htm>

From angorya at openjdk.org  Tue Mar 18 21:42:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Mar 2025 21:42:26 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
Message-ID: <pS95TaFdfvBY1FjBr0jpoUwR129YoUxoGtKkR4G1bmQ=.dee90563-c9db-40e6-8b18-e40d14daa755@github.com>

On Mon, 17 Mar 2025 18:54:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable preview features in tests

Standard windows buttons appear blurry and smaller at 100% scale:

![Screenshot 2025-03-18 143305](https://github.com/user-attachments/assets/08608f86-017a-41ac-95c6-60deb14456de)

For reference, here are other resolutions (I could not get 225% scale on my laptop) - scale is at the bottom of the main window:

![Screenshot 2025-03-18 142924](https://github.com/user-attachments/assets/604420b4-074d-49a7-99a2-caf2a0ea4079)
![Screenshot 2025-03-18 143044](https://github.com/user-attachments/assets/1eb94730-21e2-4c53-adcf-5ec08e3a49f6)
![Screenshot 2025-03-18 143152](https://github.com/user-attachments/assets/f91ceb24-ce8a-4d53-b554-b1de45c18424)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2734796223
PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2734800080

From angorya at openjdk.org  Tue Mar 18 21:46:27 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Mar 2025 21:46:27 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
Message-ID: <Wdq-T8JcPWKdV51iV4dJUW8LU1GBI3Ne3vFsNXqzTLo=.4c847953-d5d4-41d8-8c4c-b732d236fc23@github.com>

On Mon, 17 Mar 2025 18:54:27 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   enable preview features in tests

Preview feature works as designed - there is an exception when trying to access the feature:

Exception in thread "JavaFX Application Thread" java.lang.RuntimeException: StageStyle.EXTENDED_UTILITY is a preview feature of JavaFX 25-internal.
Preview features may be removed in a future release, or upgraded to permanent features of JavaFX.
Programs can only use preview features when the following system property is set: -Djavafx.enablePreview=true

	at javafx.base/com.sun.javafx.PreviewFeature.checkEnabled(PreviewFeature.java:80)
	at javafx.graphics/javafx.stage.Stage.initStyle(Stage.java:471)


Once -Djavafx.enablePreview=true` is set, the feature runs:



Note: This program uses the following preview feature of JavaFX 25-internal: StageStyle.EXTENDED
      Preview features may be removed in a future release, or upgraded to permanent features of JavaFX.
      This warning can be disabled with the following system property: -Djavafx.suppressPreviewWarning=true
Note: This program uses the following preview feature of JavaFX 25-internal: HeaderBar
      Preview features may be removed in a future release, or upgraded to permanent features of JavaFX.
      This warning can be disabled with the following system property: -Djavafx.suppressPreviewWarning=true


and adding -Djavafx.suppressPreviewWarning=true` disables the warnings.

Nice.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2734810757

From angorya at openjdk.org  Tue Mar 18 21:51:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 18 Mar 2025 21:51:24 GMT
Subject: RFR: 8352268: [TestBug] Saving in Rich Editor Demo
Message-ID: <CAOqp-h45UDjibMM0LShhorGqUn2pIgFW7SY1WuoCQA=.b2859e2f-fdb4-437f-8695-5e7b688d63e4@github.com>

Fixes embarrassing bugs in Rich Editor Demo:

- File -> Save not saving
- File -> Open not emphasizing .rich files

-------------

Commit messages:
 - save

Changes: https://git.openjdk.org/jfx/pull/1739/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1739&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352268
  Stats: 17 lines in 1 file changed: 6 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jfx/pull/1739.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1739/head:pull/1739

PR: https://git.openjdk.org/jfx/pull/1739

From jhendrikx at openjdk.org  Tue Mar 18 23:47:13 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 18 Mar 2025 23:47:13 GMT
Subject: RFR: 8351867: No UI changes while iconified
In-Reply-To: <XPdttsrpzcsHIeQOiL9zXvLrupGgFc2fnEd7Y4O9qec=.1b9cddf0-8b48-4704-8ae9-e600ae04a631@github.com>
References: <yRxYTTVWB-gETuAna9XNfdHyN_Tf5bZwJzppuqpwdjU=.a5e7038d-189a-4c27-9b81-e6d3218087c8@github.com>
 <XPdttsrpzcsHIeQOiL9zXvLrupGgFc2fnEd7Y4O9qec=.1b9cddf0-8b48-4704-8ae9-e600ae04a631@github.com>
Message-ID: <ngYmwjpTmNs9z1cQtZxvZkONewsKy57SQSvVkqepaVA=.473e387c-a6e7-4395-9bd4-e7610c6bbadb@github.com>

On Tue, 18 Mar 2025 15:01:46 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> This does fix the issue on windows. The issue on mac seems intermittent even without this change, and stays intermittent with this change.
> 
> The change seems to achieve the intended but the trigger check may not be the best way. `updateSceneState` is used when there are any changes with scene properties. The redraw should be triggered by checking the change in scene graph. This change just triggers irrespective of that.

I think the bug can also appear without the scene graph having changed, when you iconify immediately programmatically (ie. before showing the window).  The change detection would need to make sure it also detects the case where a scene was not drawn yet at all:


public class App extends Application {

    public static void main(String[] args) {
        Application.launch(args);
    }

    @Override
    public void start(Stage stage) {
        Scene scene = new Scene(new Label("This should be modified when the signal is received"), 500, 500);

        stage.setScene(scene);

        stage.setIconified(true);
        stage.show();
    }
}

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1733#issuecomment-2734965738

From mstrauss at openjdk.org  Wed Mar 19 12:36:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 19 Mar 2025 12:36:22 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v3]
In-Reply-To: <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
 <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>
Message-ID: <WCYppc9PXXo0DCqYgS4pMTaExpOGJYpwkH5A5k1_IUQ=.4512df1b-3028-4fd0-b63d-22334f42a3ba@github.com>

On Tue, 18 Mar 2025 16:57:31 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> - synchronized `EventType::register()` method
>> - simplified internal constructor which is only used for `EventType.ROOT`
>> 
>> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
>> 
>> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - formatting
>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>  - ignored
>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>  - test
>  - synchronized

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1729#pullrequestreview-2698244536

From kevin.rushforth at oracle.com  Wed Mar 19 12:37:47 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Mar 2025 05:37:47 -0700
Subject: JavaFX 24 General Availability
Message-ID: <4f1e2186-77b1-4ddf-a411-a6753cb9b577@oracle.com>

We released JavaFX 24 yesterday in connection with the JDK 24 release 
[1]. Binaries from Oracle can be download from jdk.java.net at:

https://jdk.java.net/javafx24/

They can also be downloaded from:

https://openjfx.io/

-- Kevin

[1] https://mail.openjdk.org/pipermail/jdk-dev/2025-March/009843.html


From kevin.rushforth at oracle.com  Wed Mar 19 12:39:00 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 19 Mar 2025 05:39:00 -0700
Subject: JavaFX 24 General Availability
In-Reply-To: <4f1e2186-77b1-4ddf-a411-a6753cb9b577@oracle.com>
References: <4f1e2186-77b1-4ddf-a411-a6753cb9b577@oracle.com>
Message-ID: <10827c3f-e82e-4eed-b4b2-ae2136c8f15c@oracle.com>

Release notes are available here:

https://github.com/openjdk/jfx/blob/jfx24/doc-files/release-notes-24.md

On 3/19/2025 5:37 AM, Kevin Rushforth wrote:
> We released JavaFX 24 yesterday in connection with the JDK 24 release 
> [1]. Binaries from Oracle can be download from jdk.java.net at:
>
> https://jdk.java.net/javafx24/
>
> They can also be downloaded from:
>
> https://openjfx.io/
>
> -- Kevin
>
> [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-March/009843.html
>


From angorya at openjdk.org  Wed Mar 19 14:18:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Mar 2025 14:18:30 GMT
Subject: RFR: 8351038: ConcurrentModificationException in EventType
 constructor [v3]
In-Reply-To: <Z03dFZkNWMHvhsod_2wZRMkgB2oEzK-M3HvyvTANKWA=.86590cfc-6c47-44d6-b415-059b692b5f99@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
 <5gPP8eq1IofkFOrH3CigKThnKAzElbeE3bJ2PufJT34=.4ff609c3-b73c-446b-be9b-c455fddb9361@github.com>
 <Z03dFZkNWMHvhsod_2wZRMkgB2oEzK-M3HvyvTANKWA=.86590cfc-6c47-44d6-b415-059b692b5f99@github.com>
Message-ID: <dkg3xWwV0rldt1MDXLO7uSjxnvnEZjpicwf9wGVuvaA=.2ff3b7cb-8e85-4a06-8765-333df43edc49@github.com>

On Tue, 18 Mar 2025 17:05:17 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - formatting
>>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>>  - ignored
>>  - Merge remote-tracking branch 'origin/master' into 8351038.event.type
>>  - test
>>  - synchronized
>
> Marked as reviewed by arapte (Reviewer).

Thank you for reviewing @arapte @mstr2 !

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1729#issuecomment-2736805122

From angorya at openjdk.org  Wed Mar 19 14:18:30 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Mar 2025 14:18:30 GMT
Subject: Integrated: 8351038: ConcurrentModificationException in EventType
 constructor
In-Reply-To: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
References: <PUpJQ1UOvwZk3plBKAHqx4Mt4wIs5edlCe_IlyxfCCs=.d31604be-86bf-496d-8a0c-f69ee196c51b@github.com>
Message-ID: <aA5xZBhXLXHIPlrimJyRLx0SJ2UFcRyK9iAn6krj9Xk=.b28ae5bb-b058-45f2-adfc-0b7036fcee68@github.com>

On Wed, 5 Mar 2025 18:40:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> - synchronized `EventType::register()` method
> - simplified internal constructor which is only used for `EventType.ROOT`
> 
> There should negligent impact on performance when `EventTypes` are created in the FX Application Thread.
> 
> There might be a distant potential for a deadlock if the application wraps code that creates `EventTypes` in a block synchronized on a different object.

This pull request has now been integrated.

Changeset: 0e509616
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0e50961631ebaa2ac2fc5132f0e4c8c3efa72d3d
Stats:     83 lines in 2 files changed: 64 ins; 13 del; 6 mod

8351038: ConcurrentModificationException in EventType constructor

Reviewed-by: arapte, mstrauss

-------------

PR: https://git.openjdk.org/jfx/pull/1729

From kcr at openjdk.org  Wed Mar 19 20:06:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 19 Mar 2025 20:06:15 GMT
Subject: RFR: 8352268: RichEditorDemo: Save file doesn't always save
In-Reply-To: <CAOqp-h45UDjibMM0LShhorGqUn2pIgFW7SY1WuoCQA=.b2859e2f-fdb4-437f-8695-5e7b688d63e4@github.com>
References: <CAOqp-h45UDjibMM0LShhorGqUn2pIgFW7SY1WuoCQA=.b2859e2f-fdb4-437f-8695-5e7b688d63e4@github.com>
Message-ID: <mq7QrOB9ruWOjVZVCLuLNBCAd3K7zTY5vyoc0PmxJSk=.04f9c346-3391-47a0-837e-f693b307c32c@github.com>

On Tue, 18 Mar 2025 20:43:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes embarrassing bugs in Rich Editor Demo:
> 
> - File -> Save not saving
> - File -> Open not emphasizing .rich files

Looks good. I tried the work flow that failed for me earlier and it now works.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1739#pullrequestreview-2700023869

From angorya at openjdk.org  Wed Mar 19 20:06:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 19 Mar 2025 20:06:16 GMT
Subject: Integrated: 8352268: RichEditorDemo: Save file doesn't always save
In-Reply-To: <CAOqp-h45UDjibMM0LShhorGqUn2pIgFW7SY1WuoCQA=.b2859e2f-fdb4-437f-8695-5e7b688d63e4@github.com>
References: <CAOqp-h45UDjibMM0LShhorGqUn2pIgFW7SY1WuoCQA=.b2859e2f-fdb4-437f-8695-5e7b688d63e4@github.com>
Message-ID: <ELhvgwTpjek9G-gyjp1-pklY50rjVMOgeJxquGeAqck=.eea20add-224a-444a-8be1-11d6b89eee61@github.com>

On Tue, 18 Mar 2025 20:43:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Fixes embarrassing bugs in Rich Editor Demo:
> 
> - File -> Save not saving
> - File -> Open not emphasizing .rich files

This pull request has now been integrated.

Changeset: 0eda4df2
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/0eda4df202c07beda00bd282681b6755c1602661
Stats:     17 lines in 1 file changed: 6 ins; 4 del; 7 mod

8352268: RichEditorDemo: Save file doesn't always save

Reviewed-by: kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1739

From angorya at openjdk.org  Thu Mar 20 14:46:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Mar 2025 14:46:26 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <4M2TFEZZtnecEazTSjwJIFRVCRpJ6mswT4XZMMyIHuY=.2d0a54cf-c943-4ba9-be53-b93bca1e37ec@github.com>

On Wed, 19 Feb 2025 16:50:02 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

I think it currently looks good, even though `PasswordField` lost its portion of tests.  Since we know the `PasswordField` implementation does not add any functionality in the area being tested, the TextFieldTest should be sufficient.

Left some minor comments.

I would like to have another pair of eyes though.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 29:

> 27: 
> 28: import java.util.List;
> 29: import javafx.beans.binding.*;

please do not use wildcard imports

modules/javafx.controls/src/test/java/test/javafx/scene/control/TextAreaTest.java line 28:

> 26: package test.javafx.scene.control;
> 27: 
> 28: import static org.junit.jupiter.api.Assertions.*;

please do not use wildcard imports

-------------

PR Review: https://git.openjdk.org/jfx/pull/1716#pullrequestreview-2703011020
PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2005798638
PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2005800412

From mstrauss at openjdk.org  Thu Mar 20 20:02:21 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Thu, 20 Mar 2025 20:02:21 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <4M2TFEZZtnecEazTSjwJIFRVCRpJ6mswT4XZMMyIHuY=.2d0a54cf-c943-4ba9-be53-b93bca1e37ec@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <4M2TFEZZtnecEazTSjwJIFRVCRpJ6mswT4XZMMyIHuY=.2d0a54cf-c943-4ba9-be53-b93bca1e37ec@github.com>
Message-ID: <a9vAMZsyXaw2-XchobKO_P6_MafGvIbeaYUdq78df3c=.3165d354-7dae-495e-b83d-97494e1dc901@github.com>

On Thu, 20 Mar 2025 14:38:16 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TextAreaTest.java line 28:
> 
>> 26: package test.javafx.scene.control;
>> 27: 
>> 28: import static org.junit.jupiter.api.Assertions.*;
> 
> please do not use wildcard imports

In tests, and especially for assertions, wildcard imports are usually accepted. We use them all over the place. However, I would agree that symbols other than assertions should usually be fully qualified.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2006358989

From angorya at openjdk.org  Thu Mar 20 20:06:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 20 Mar 2025 20:06:26 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <a9vAMZsyXaw2-XchobKO_P6_MafGvIbeaYUdq78df3c=.3165d354-7dae-495e-b83d-97494e1dc901@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <4M2TFEZZtnecEazTSjwJIFRVCRpJ6mswT4XZMMyIHuY=.2d0a54cf-c943-4ba9-be53-b93bca1e37ec@github.com>
 <a9vAMZsyXaw2-XchobKO_P6_MafGvIbeaYUdq78df3c=.3165d354-7dae-495e-b83d-97494e1dc901@github.com>
Message-ID: <CIoIVA5priWDYvojKvscw8tjJXFPIper2ujsJLqkvp8=.04b5c0fc-a59c-4db7-b90f-5ebee65c5fd6@github.com>

On Thu, 20 Mar 2025 19:59:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TextAreaTest.java line 28:
>> 
>>> 26: package test.javafx.scene.control;
>>> 27: 
>>> 28: import static org.junit.jupiter.api.Assertions.*;
>> 
>> please do not use wildcard imports
>
> In tests, and especially for assertions, wildcard imports are usually accepted. We use them all over the place. However, I would agree that symbols other than assertions should usually be fully qualified.

good point

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2006364185

From mstrauss at openjdk.org  Fri Mar 21 06:03:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 21 Mar 2025 06:03:28 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <vB89NAhNgUAMbiGRorN4Q-vC3hJTmS0PnAmysgQ8KRg=.7292d909-b917-4b61-ad96-b7e6d226b516@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <Ieb_X7SRc5_KUnwT_LCZlJoU_P9eJIxtF8FFmIQwi_I=.2ab842aa-413d-4243-9ab4-2b32b191c9a2@github.com>
 <vB89NAhNgUAMbiGRorN4Q-vC3hJTmS0PnAmysgQ8KRg=.7292d909-b917-4b61-ad96-b7e6d226b516@github.com>
Message-ID: <ILtZzj3UOyf_eBFIMgYcTha3baLn-OY6pWDIMeVJESc=.9646501e-5d7e-4d0f-b378-df317d742a0d@github.com>

On Sun, 16 Mar 2025 09:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 739:
>> 
>>> 737:             s = s.replace("\n", "");
>>> 738:             return s;
>>> 739:         }, getSkinnable().promptTextProperty()));
>> 
>> two minor problems:
>> 1. missing { } after `if`.  (I would highly recommend always using { })
>> 2. when s is null you call replace() unnecessarily
>> 
>> suggestion:
>> 
>>             String s = getSkinnable().getPromptText();
>>             if (s == null) {
>>                 return "";
>>             }
>>             return s.replace("\n", "");
>
> You should consider using a fluent binding here, which is a more modern solution compared to the `Bindings` class. It is also simpler because you don't need to check for `null`:
> 
> 
> promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));

Have you considered the suggestion?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2006899928

From mstrauss at openjdk.org  Fri Mar 21 06:09:16 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 21 Mar 2025 06:09:16 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <gYdlUoYnBXPEZDPnELpwEItixqWn0qmTi-71Oo9-3yU=.9bb75bf2-c897-45ab-a516-40a43133500e@github.com>

On Wed, 19 Feb 2025 16:50:02 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

I think that we should treat all _usual_ line separators in the same way (that is, `\n`, `\r`, and `\r\n`), as I don?t know if we have a specification that only one kind of line separator visually breaks lines in JavaFX.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2742415030

From jbhaskar at openjdk.org  Fri Mar 21 08:21:47 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Fri, 21 Mar 2025 08:21:47 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit 620.1
Message-ID: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>

Issue: 
Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
In the case of the canvas pattern using a transform property filled with an SVGMatrix()
created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
as the image decoder has already populated `frame.m_size` during image metadata caching.

Solution:
To avoid potential invalid accesses and unintended size resets, only update `m_size`
if the frame does not already have a valid native image.

-------------

Commit messages:
 - 8347937: Canvas pattern test fails and crashes on WebKit 620.1

Changes: https://git.openjdk.org/jfx/pull/1740/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1740&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347937
  Stats: 20 lines in 2 files changed: 18 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1740.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1740/head:pull/1740

PR: https://git.openjdk.org/jfx/pull/1740

From quizynox at gmail.com  Fri Mar 21 10:29:49 2025
From: quizynox at gmail.com (quizynox at gmail.com)
Date: Fri, 21 Mar 2025 14:29:49 +0400
Subject: How to use jfx.incubator mdoules?
Message-ID: <CAASO9vRCYn=YNFpgjwpMMoCnxz_4Y4OGiS99fEC4x61jVud1dw@mail.gmail.com>

Hello,

I'm very excited to try the recent incubated features. Thank you all for
the great job! Could someone please explain how to use them? They are
separate modules, but I don't see them published to Maven Central, and they
aren't included as transitive dependencies for existing modules either. Am
I supposed to compile JavaFX locally?

Best Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250321/acf3eb77/attachment-0001.htm>

From snazarki at openjdk.org  Fri Mar 21 10:41:47 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 21 Mar 2025 10:41:47 GMT
Subject: Withdrawn: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
Message-ID: <dO1KIzqfaOGblGb31Dgi59_wShEvgeQLbsbj_Mynwbg=.2374ac75-7c06-4b92-83e6-9bb16bb32890@github.com>

On Thu, 13 Mar 2025 18:17:53 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
> 
> #  What is the problem?
> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
> Stack trace
> 
>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000...

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jfx/pull/1734

From snazarki at openjdk.org  Fri Mar 21 10:41:47 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 21 Mar 2025 10:41:47 GMT
Subject: RFR: 8347937: Canvas pattern test fails on WebKit 620.1
In-Reply-To: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
References: <-wgglUkT32pasoL0XjqKiWc5NROVyj9_wz7gDqmvrUA=.cf2ee273-5363-4470-8e8a-6674e70a2023@github.com>
Message-ID: <f-v6AMHE8Psf0CCHQQoWKklBZshza4WSUiqIMtyAxvg=.faeb1e30-d6a4-40ba-a3c7-4753dc8aa3b0@github.com>

On Thu, 13 Mar 2025 18:17:53 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> Hi!
> 
> This is my desperate fix for what I believe to be a critical bug. Since my knowledge of the codebase is minimal, and the class structure is a bit controversial, my fix is mostly based on historical excavation.
> 
> #  What is the problem?
> VM started to crash after webkit 620.1 update when running simple [CanvasTest](https://github.com/openjdk/jfx/blob/1c3cfcb8bb4e8874406d3a5b507f38859f4c1d9b/modules/javafx.web/src/test/java/test/javafx/scene/web/CanvasTest.java#L125).  Running with `-Xcheck:jni ` reveals invalid object is passed to JNI [call](https://github.com/openjdk/jfx/blob/0555fb25a16b6b6705a42c6d8592cf1c6ddccc67/modules/javafx.web/src/main/native/Source/WebCore/platform/graphics/java/NativeImageJava.cpp#L56): expected is`WCImageFrame` but provided is `RTImage` (an descendant of `WCImage`). The latter has no `getSize` method.
> Stack trace
> 
>     frame #4: 0x0000000101a36094 libjvm.dylib`checked_jni_CallObjectMethodV(env=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8, args="\xa0\U00000012\U0000001ev\U00000001") at jniCheck.cpp:1012:1 [opt]
>     frame #5: 0x000000033e88ea60 libjfxwebkit.dylib`JNIEnv_::CallObjectMethod(this=0x0000000124a89cb0, obj=0x000000012310f9e8, methodID=0x00006000019abde8) at jni.h:906:18
>     frame #6: 0x00000003426fcda0 libjfxwebkit.dylib`WebCore::PlatformImageNativeImageBackend::size(this=0x0000600000e12790) const at NativeImageJava.cpp:55:48
>     frame #7: 0x000000034258d76c libjfxwebkit.dylib`WebCore::NativeImage::size(this=0x00000001761c2c00) const at NativeImage.cpp:89:23
>     frame #8: 0x00000003425723c0 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:40:29
>     frame #9: 0x0000000342572420 libjfxwebkit.dylib`WebCore::ImageFrame::ImageFrame(this=0x00000001761e1270, nativeImage=0x000000016fdf7090) at ImageFrame.cpp:39:1
>     frame #10: 0x00000003425a4d7c libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:37:7
>     frame #11: 0x00000003425a4d24 libjfxwebkit.dylib`WebCore::NativeImageSource::NativeImageSource(this=0x00000001761e1260, nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:38:1
>     frame #12: 0x00000003425a4cac libjfxwebkit.dylib`WebCore::NativeImageSource::create(nativeImage=0x000000016fdf7090) at NativeImageSource.cpp:33:26
>     frame #13: 0x00000003423a6f18 libjfxwebkit.dylib`WebCore::BitmapImage::BitmapImage(this=0x00000...

Closed in favour of https://github.com/openjdk/jfx/pull/1740

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1734#issuecomment-2742973755

From snazarki at openjdk.org  Fri Mar 21 10:57:25 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 21 Mar 2025 10:57:25 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <9QhX71a4JtLQC1xtwGuC4f0ELmmlfobwpdR-OsEWST8=.6f3f17b5-f1ad-43a4-8934-c56341af6e27@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

I see CanvasTest failure. But I guess it is unrelated

CanvasTest > testCanvasPattern() FAILED
    org.opentest4j.AssertionFailedError: First rect top-left ==> expected: <255> but was: <0>

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2743013599

From kcr at openjdk.org  Fri Mar 21 12:43:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 12:43:21 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <9QhX71a4JtLQC1xtwGuC4f0ELmmlfobwpdR-OsEWST8=.6f3f17b5-f1ad-43a4-8934-c56341af6e27@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
 <9QhX71a4JtLQC1xtwGuC4f0ELmmlfobwpdR-OsEWST8=.6f3f17b5-f1ad-43a4-8934-c56341af6e27@github.com>
Message-ID: <erDEGrsDFzbcdvcmvbvpIvD6wvwn7_nbcszqL4qg3_A=.904b2fbc-5440-4e05-a7ab-e6ca956e0a51@github.com>

On Fri, 21 Mar 2025 10:54:58 GMT, Sergey Nazarkin <snazarki at openjdk.org> wrote:

> I see CanvasTest failure. But I guess it is unrelated
> 
> ```
> CanvasTest > testCanvasPattern() FAILED
>     org.opentest4j.AssertionFailedError: First rect top-left ==> expected: <255> but was: <0>
> ```

@snazarkin This failure is unexpected. We ran a CI build and the test passes for us. How did you run the test?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2743252976

From kcr at openjdk.org  Fri Mar 21 13:10:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 13:10:17 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <Z392Zq9ckWbbCzyX0dQdv1BP4m8XqeXQDKUXC0OhG3U=.1da611be-8453-4c5d-8d02-2c1865335123@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

The fix looks good to me. I confirmed that the formerly crashing CanvasTest now passes for me on my Mac M1. I'll do some additional testing before approving.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2743317756

From snazarki at openjdk.org  Fri Mar 21 13:59:21 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 21 Mar 2025 13:59:21 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <hnHxm8MxqCiomm6thQVXInwEOEjBSLZpEM1pdRSvGL8=.ca141456-4789-4555-9aa2-ec52b7c4075c@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

Run with `-Xcheck:jni `: no error found

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2743442750

From snazarki at openjdk.org  Fri Mar 21 13:59:20 2025
From: snazarki at openjdk.org (Sergey Nazarkin)
Date: Fri, 21 Mar 2025 13:59:20 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <erDEGrsDFzbcdvcmvbvpIvD6wvwn7_nbcszqL4qg3_A=.904b2fbc-5440-4e05-a7ab-e6ca956e0a51@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
 <9QhX71a4JtLQC1xtwGuC4f0ELmmlfobwpdR-OsEWST8=.6f3f17b5-f1ad-43a4-8934-c56341af6e27@github.com>
 <erDEGrsDFzbcdvcmvbvpIvD6wvwn7_nbcszqL4qg3_A=.904b2fbc-5440-4e05-a7ab-e6ca956e0a51@github.com>
Message-ID: <3_EkudYdyomq_BMPgnEN-bHpJJpIYnJ65Kr-XvGZ_2M=.cc52ab27-a150-446c-b922-348331e575c6@github.com>

On Fri, 21 Mar 2025 12:40:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > I see CanvasTest failure. But I guess it is unrelated
> > ```
> > CanvasTest > testCanvasPattern() FAILED
> >     org.opentest4j.AssertionFailedError: First rect top-left ==> expected: <255> but was: <0>
> > ```
> 
> @snazarkin This failure is unexpected. We ran a CI build and the test passes for us. How did you run the test?

macbook m2, clean repo with applied patch.  JDK22, Xcode 14.3

./gradlew -PCOMPILE_MEDIA=true -PCOMPILE_WEBKIT=true --info :web:test


Now with third clean run I see no error. May be there were some leftovers from developers builds.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2743438819

From zelmidaoui at openjdk.org  Fri Mar 21 14:37:56 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 21 Mar 2025 14:37:56 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v2]
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <bQZFS4BmXRUPppslEXBZ_BNXLbuJr3YkKW5spPrmLyc=.d5850ce8-87d8-4e0b-977f-d57c40b47c0a@github.com>

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  changed wildcard imports

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1716/files
  - new: https://git.openjdk.org/jfx/pull/1716/files/358ac0a5..68b0c868

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=00-01

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1716.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1716/head:pull/1716

PR: https://git.openjdk.org/jfx/pull/1716

From zelmidaoui at openjdk.org  Fri Mar 21 14:37:56 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 21 Mar 2025 14:37:56 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v2]
In-Reply-To: <CIoIVA5priWDYvojKvscw8tjJXFPIper2ujsJLqkvp8=.04b5c0fc-a59c-4db7-b90f-5ebee65c5fd6@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <4M2TFEZZtnecEazTSjwJIFRVCRpJ6mswT4XZMMyIHuY=.2d0a54cf-c943-4ba9-be53-b93bca1e37ec@github.com>
 <a9vAMZsyXaw2-XchobKO_P6_MafGvIbeaYUdq78df3c=.3165d354-7dae-495e-b83d-97494e1dc901@github.com>
 <CIoIVA5priWDYvojKvscw8tjJXFPIper2ujsJLqkvp8=.04b5c0fc-a59c-4db7-b90f-5ebee65c5fd6@github.com>
Message-ID: <fi7XQga1bkAICvsw0KbSZZhFNRwQXt4E-1HsbTN4iLs=.789a1c89-58ab-49a1-8e00-2addf8786385@github.com>

On Thu, 20 Mar 2025 20:03:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> In tests, and especially for assertions, wildcard imports are usually accepted. We use them all over the place. However, I would agree that symbols other than assertions should usually be fully qualified.
>
> good point

I kept the wildcards for assertions and removed others
thanks for mentioning them

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2007719483

From kevin.rushforth at oracle.com  Fri Mar 21 17:04:55 2025
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 21 Mar 2025 10:04:55 -0700
Subject: How to use jfx.incubator mdoules?
In-Reply-To: <CAASO9vRCYn=YNFpgjwpMMoCnxz_4Y4OGiS99fEC4x61jVud1dw@mail.gmail.com>
References: <CAASO9vRCYn=YNFpgjwpMMoCnxz_4Y4OGiS99fEC4x61jVud1dw@mail.gmail.com>
Message-ID: <b1a0a49d-0739-4cc1-8e46-e2156ec731b2@oracle.com>

Hi,

Johan can answer your question about publishing to maven central. I can 
confirm that the jar files for publication are being generated.

Incubator modules are not in the list of transitive dependencies for any 
existing module -- nor should they be, since incubator modules must be 
explicitly requested and are not depended on by other non-incubator 
modules. You would need to explicitly declare a dependency on the 
incubator module.

As for how to use them without relying on Maven Central, you can 
download the JMODs or SDK from https://jdk.java.net/javafx24 or 
https://openjfx.io and then use jlink (if using the JMODs) to create a 
custom JDK that includes JavaFX or use --module-path, if using the SDK. See:

https://openjfx.io/openjfx-docs/

And look at the "Runtime images" or "Run HelloWorld using JavaFX SDK" 
sections of the doc.

Either way you will need to use "--add-modules jfx.incubator.richtext" 
since incubator modules are (intentionally) not resolved by default.

-- Kevin


On 3/21/2025 3:29 AM, quizynox at gmail.com wrote:
> Hello,
>
> I'm very excited?to try the?recent incubated features. Thank you all 
> for the great job! Could someone please explain how to use?them? They 
> are separate modules, but I don't see them published to Maven Central, 
> and they aren't included as transitive dependencies for existing 
> modules either. Am I supposed to compile JavaFX locally?
>
> Best Regards.


From kcr at openjdk.org  Fri Mar 21 17:52:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 17:52:16 GMT
Subject: [jfx24u] RFR: Merge jfx:jfx24
Message-ID: <E7EQ7zvpJL_wzTS4vkr9qAiSxFkxZSDjqNbygt3nl80=.19b6fe13-a0dc-4998-8a23-ca6402834414@github.com>

Clean merge from `jfx:jfx24` branch to `jfx24u:master`. This is the final merge to pick up the release notes for JavaFX 24.

-------------

Commit messages:
 - Merge remote-tracking branch 'jfx/jfx24' into merge-jfx-jfx24-to-master-2025-03-21
 - 8350136: Create release notes for JavaFX 24

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jfx24u/pull/15/files
  Stats: 275 lines in 2 files changed: 275 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/15.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/15/head:pull/15

PR: https://git.openjdk.org/jfx24u/pull/15

From kcr at openjdk.org  Fri Mar 21 17:56:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 17:56:12 GMT
Subject: [jfx24u] Integrated: Merge jfx:jfx24
In-Reply-To: <E7EQ7zvpJL_wzTS4vkr9qAiSxFkxZSDjqNbygt3nl80=.19b6fe13-a0dc-4998-8a23-ca6402834414@github.com>
References: <E7EQ7zvpJL_wzTS4vkr9qAiSxFkxZSDjqNbygt3nl80=.19b6fe13-a0dc-4998-8a23-ca6402834414@github.com>
Message-ID: <nMOZUZwgAWu2KhDGg_M3lBxWd3IcbpF8Bi8cQXRcB-Q=.d8d52e7a-2cbe-4b14-a4b6-4c0d52bdf187@github.com>

On Fri, 21 Mar 2025 17:47:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Clean merge from `jfx:jfx24` branch to `jfx24u:master`. This is the final merge to pick up the release notes for JavaFX 24.

This pull request has now been integrated.

Changeset: 4b94e821
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/4b94e8211bedfa75a7b7da87118ecb146556d847
Stats:     275 lines in 2 files changed: 275 ins; 0 del; 0 mod

Merge

-------------

PR: https://git.openjdk.org/jfx24u/pull/15

From angorya at openjdk.org  Fri Mar 21 18:35:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Mar 2025 18:35:16 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v2]
In-Reply-To: <bQZFS4BmXRUPppslEXBZ_BNXLbuJr3YkKW5spPrmLyc=.d5850ce8-87d8-4e0b-977f-d57c40b47c0a@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <bQZFS4BmXRUPppslEXBZ_BNXLbuJr3YkKW5spPrmLyc=.d5850ce8-87d8-4e0b-977f-d57c40b47c0a@github.com>
Message-ID: <6LVfF8ZE5A_6MXipdiRxmAt3DGa_h1kRYsvKjDWeWZo=.dceefcff-8e40-4bc7-86f4-a8fa2eb0b6cd@github.com>

On Fri, 21 Mar 2025 14:37:56 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed wildcard imports

Confirming that no other character (see earlier comment) other than LF render as newlines, on macOS and Windows.

The ticket mentions a possible "workaround" of using \r (CR) on Windows, but it is not true.

![Screenshot 2025-03-21 112855](https://github.com/user-attachments/assets/20b39e78-fad6-4f39-b561-189de3c46240)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2744153478

From angorya at openjdk.org  Fri Mar 21 18:43:15 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Mar 2025 18:43:15 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v2]
In-Reply-To: <bQZFS4BmXRUPppslEXBZ_BNXLbuJr3YkKW5spPrmLyc=.d5850ce8-87d8-4e0b-977f-d57c40b47c0a@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <bQZFS4BmXRUPppslEXBZ_BNXLbuJr3YkKW5spPrmLyc=.d5850ce8-87d8-4e0b-977f-d57c40b47c0a@github.com>
Message-ID: <BK9P0vXtecWbjOt5E87Hc9ECPrQL-Yh0ACvm5hDw1fg=.a6fd3c1f-6447-4fe5-a939-1f12ea03826d@github.com>

On Fri, 21 Mar 2025 14:37:56 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed wildcard imports

@Ziad-Mid : 
please do not resolve the conversations without the original commenter confirming that the conversation is resolved (it's really a bug in guthub, as only the originator of the comment can say if the conversation has been resolved).  I think there are still some questions left unanswered, please check.

(I've started to use thumbs-up emoji to mark the comment as addressed, if you want my opinion).

Other than that, the changes look good to me.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1716#pullrequestreview-2706932973

From mfox at openjdk.org  Fri Mar 21 21:00:46 2025
From: mfox at openjdk.org (Martin Fox)
Date: Fri, 21 Mar 2025 21:00:46 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event loops
Message-ID: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>

There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.

This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.

On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

-------------

Commit messages:
 - Merge remote-tracking branch 'upstream/master' into toomanyloops
 - Moved some asserts so they're not inside runLater blocks.
 - Mac nows throws exception before we hit the limit on nested CFRunLoopRun calls

Changes: https://git.openjdk.org/jfx/pull/1741/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351733
  Stats: 101 lines in 6 files changed: 92 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From kcr at openjdk.org  Fri Mar 21 21:07:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 21:07:15 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <fyiviM1f-yLDEiteJsxGEVjd141H_oUx6Ry5MPyy4po=.6f5ed4ec-aa7c-4af3-87c0-ddfe36d2108c@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

Additional testing looks good.

@arapte or @aghaisas Can one of you be the second reviewer?

@snazarkin Any additional feedback?

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1740#pullrequestreview-2707256184
PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2744445116

From kcr at openjdk.org  Fri Mar 21 21:13:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 21:13:18 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <UmnMIn0ZIdYOU0hmlP9iWv_StBz27zUzo4YvVnxOn04=.c9129cad-1e96-43b7-a69b-02af36ac1bc3@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

I attached a simple `canvas.html`, taken from the failing CanvasTest unit test to the JBS bug. That test fails to render on WebKit 620.1 (although, unlike the unit test, it doesn't crash) without this fix and renders correctly with this fix.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1740#issuecomment-2744454664

From kcr at openjdk.org  Fri Mar 21 21:21:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 21 Mar 2025 21:21:12 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <EVwMizWIThGitrmaHupuj706szC0gf7uzA9tw4BLtcU=.62d69cbc-addf-46e1-ba2e-2993e96d44d7@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

If the hard-coded 250 is a robust limit, then the fix looks reasonable to me. I'll test it and finish the review next week.

modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:

> 757: + (BOOL)canStartNestedEventLoop
> 758: {
> 759:     return nestedRunLoopRunCount <= 250;

How sure are you that 250 is a safe limit? Are there situations where we might not be able to do this many?

I recommend added a comment as to where the magic number "250" comes from. And maybe put it in a static const variable?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2707278351
PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2008341553

From angorya at openjdk.org  Fri Mar 21 21:28:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Mar 2025 21:28:12 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <9stOE4xTqbFLV_KH2mkSXZKrV8gjlADzARGmz9KSSWM=.566c1a54-c70e-4da9-b153-6573c87793b3@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:

> 757: + (BOOL)canStartNestedEventLoop
> 758: {
> 759:     return nestedRunLoopRunCount <= 250;

would it be possible to determine the source of this limit - a header perhaps?
could it be dependent on os version?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2008350233

From angorya at openjdk.org  Fri Mar 21 21:33:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Mar 2025 21:33:26 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <TgtuwxDOsm1C5fs_BzeZPMiNtpxVPjjnjbjCK0_eYyg=.f77f50f4-a086-44b4-962a-0fe9d614027c@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 778:

> 776:                        beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.010]];
> 777:         nestedRunLoopRunCount -= 1;
> 778:         if (ran) {

I could be wrong reading this code, but doesn't the `nestedRunLoopRunCount` value remain unchanged?  L774 gets always cancelled by L777?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2008356000

From angorya at openjdk.org  Fri Mar 21 22:05:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 21 Mar 2025 22:05:21 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <TgtuwxDOsm1C5fs_BzeZPMiNtpxVPjjnjbjCK0_eYyg=.f77f50f4-a086-44b4-962a-0fe9d614027c@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <TgtuwxDOsm1C5fs_BzeZPMiNtpxVPjjnjbjCK0_eYyg=.f77f50f4-a086-44b4-962a-0fe9d614027c@github.com>
Message-ID: <b-7LL8z8cmCClO2y3nN_nF5xgpkksDY_im18S63ETmc=.740ca067-18f0-40e5-a9cd-190dbe6773c7@github.com>

On Fri, 21 Mar 2025 21:30:28 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 778:
> 
>> 776:                        beforeDate:[NSDate dateWithTimeIntervalSinceNow:0.010]];
>> 777:         nestedRunLoopRunCount -= 1;
>> 778:         if (ran) {
> 
> I could be wrong reading this code, but doesn't the `nestedRunLoopRunCount` value remain unchanged?  L774 gets always cancelled by L777?

never mind, it's entering and exiting the loop there.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2008390270

From jbhaskar at openjdk.org  Sat Mar 22 02:18:15 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Sat, 22 Mar 2025 02:18:15 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <2IOCpBrhi-gFX3MtnnD8XzAnB3D5sJAeyYKr8GQOSnQ=.1f6e18a4-4658-45be-bf15-b241233b51c8@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

It is better to use dynamically calculated safe limit instead of a hardcoded value like 250. The dynamic calculation should be based on system resource and and 250 would be fallback value. like 
static int getSafeRunLoopLimit() {
    struct rlimit limit;
    if (getrlimit(RLIMIT_STACK, &limit) == 0) {
        return (int)(limit.rlim_cur / (512 * 1024)); 
    }
    return 250; // Fallback to 250 if stack size retrieval fails
}
macOS does not document an exact limit, nested CFRunLoopRun calls can cause stack growth. 512 KB is a safe approximation.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2744896944

From quizynox at gmail.com  Sat Mar 22 04:06:34 2025
From: quizynox at gmail.com (q)
Date: Sat, 22 Mar 2025 08:06:34 +0400
Subject: How to use jfx.incubator mdoules?
In-Reply-To: <b1a0a49d-0739-4cc1-8e46-e2156ec731b2@oracle.com>
References: <CAASO9vRCYn=YNFpgjwpMMoCnxz_4Y4OGiS99fEC4x61jVud1dw@mail.gmail.com>
 <b1a0a49d-0739-4cc1-8e46-e2156ec731b2@oracle.com>
Message-ID: <CAASO9vQTMsjsnEi37WOz=ieqOTPhSfjXqmBpKZXfNiZLMTOYMQ@mail.gmail.com>

Hello,

Thanks for the detailed answer! I completely forgot that JDK builds with
JavaFX included exist, and that Zulu JDK has everything I need.

Best Regards

??, 21 ???. 2025??. ? 21:05, Kevin Rushforth <kevin.rushforth at oracle.com>:

> Hi,
>
> Johan can answer your question about publishing to maven central. I can
> confirm that the jar files for publication are being generated.
>
> Incubator modules are not in the list of transitive dependencies for any
> existing module -- nor should they be, since incubator modules must be
> explicitly requested and are not depended on by other non-incubator
> modules. You would need to explicitly declare a dependency on the
> incubator module.
>
> As for how to use them without relying on Maven Central, you can
> download the JMODs or SDK from https://jdk.java.net/javafx24 or
> https://openjfx.io and then use jlink (if using the JMODs) to create a
> custom JDK that includes JavaFX or use --module-path, if using the SDK.
> See:
>
> https://openjfx.io/openjfx-docs/
>
> And look at the "Runtime images" or "Run HelloWorld using JavaFX SDK"
> sections of the doc.
>
> Either way you will need to use "--add-modules jfx.incubator.richtext"
> since incubator modules are (intentionally) not resolved by default.
>
> -- Kevin
>
>
> On 3/21/2025 3:29 AM, quizynox at gmail.com wrote:
> > Hello,
> >
> > I'm very excited to try the recent incubated features. Thank you all
> > for the great job! Could someone please explain how to use them? They
> > are separate modules, but I don't see them published to Maven Central,
> > and they aren't included as transitive dependencies for existing
> > modules either. Am I supposed to compile JavaFX locally?
> >
> > Best Regards.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250322/b2d582ec/attachment.htm>

From zelmidaoui at openjdk.org  Sat Mar 22 05:23:16 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Sat, 22 Mar 2025 05:23:16 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea
In-Reply-To: <jWTE5QH1OJ6lfLnZUNaOVBIz2zG8nBbT7i_AjNXc6Vo=.f658dc59-0cd3-4752-8602-9e999a67dd98@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <jWTE5QH1OJ6lfLnZUNaOVBIz2zG8nBbT7i_AjNXc6Vo=.f658dc59-0cd3-4752-8602-9e999a67dd98@github.com>
Message-ID: <WvkygKCJk5jUfEjZnszTIf8xeE12BF0-nT7yMHQIDNU=.ad80621b-f57a-41d3-822f-ea90306cc793@github.com>

On Tue, 18 Mar 2025 15:41:00 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> I did test the mentioned line separators without filtering and the line separators are not rendered as newlines, so there is no need to add filtering for other line separators as they are already handled by default.

> @Ziad-Mid : please do not resolve the conversations without the original commenter confirming that the conversation is resolved (it's really a bug in guthub, as only the originator of the comment can say if the conversation has been resolved). I think there are still some questions left unanswered, please check.
> 
> (I've started to use thumbs-up emoji to mark the comment as addressed, if you want my opinion).
> 
> Other than that, the changes look good to me.

I did unresolved them, and I will check the suggestions whenever possible and answer,
thanks

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1716#issuecomment-2745022759

From jhendrikx at openjdk.org  Sat Mar 22 10:23:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 22 Mar 2025 10:23:15 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v2]
In-Reply-To: <J4FDYzVlYOHGU9HzOYmTGD_UvHJ3iKLEybQIs9Q8yVE=.9f3fb5fb-1aa8-4eef-b36c-79dd58344332@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <iEuEoHBByjx_KRSXhtu8l27JmKKdVacAt1rUmghbs08=.c1d88e17-7947-43f1-91af-7dd068ee32fd@github.com>
 <J4FDYzVlYOHGU9HzOYmTGD_UvHJ3iKLEybQIs9Q8yVE=.9f3fb5fb-1aa8-4eef-b36c-79dd58344332@github.com>
Message-ID: <3R9sgpUTYDn09cDPHQrIMWBE9vNIUoqZlZcz4619cl4=.3432eb87-0ab0-4760-aced-f9a91c7e8006@github.com>

On Tue, 25 Feb 2025 00:42:04 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> John Hendrikx has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into feature/vbox-fillwidth-bug-fix
>>  - Make computeChildMin/Pref/MaxAreaHeight accept a fillWidth parameter
>
> I'll review this too.

@kevinrushforth Do you have time to take a look?  It would be good to get this in, as there are more changes I'd like to do in this area (fixing the HBox/VBox rounding errors on high DPI displays).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2745198431

From jhendrikx at openjdk.org  Sat Mar 22 12:24:20 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 22 Mar 2025 12:24:20 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
Message-ID: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>

This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.

This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.

See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

-------------

Commit messages:
 - Reuse calculations from LabeledSkinBase

Changes: https://git.openjdk.org/jfx/pull/1742/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351047
  Stats: 136 lines in 1 file changed: 40 ins; 87 del; 9 mod
  Patch: https://git.openjdk.org/jfx/pull/1742.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1742/head:pull/1742

PR: https://git.openjdk.org/jfx/pull/1742

From kcr at openjdk.org  Sat Mar 22 15:10:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Sat, 22 Mar 2025 15:10:12 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <Now5BTwsd168QB17RSZtUam_wWhsPMc91-QsSkhMOIU=.98cae836-b12e-4b8e-8145-faea9b24853f@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

Yes, sorry for the delay. This one is next on my list.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2745312913

From mfox at openjdk.org  Sat Mar 22 18:08:14 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 22 Mar 2025 18:08:14 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <9stOE4xTqbFLV_KH2mkSXZKrV8gjlADzARGmz9KSSWM=.566c1a54-c70e-4da9-b153-6573c87793b3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <9stOE4xTqbFLV_KH2mkSXZKrV8gjlADzARGmz9KSSWM=.566c1a54-c70e-4da9-b153-6573c87793b3@github.com>
Message-ID: <NlQ4JY-TACw7xWsVSavvx7RkdFP2r2hYANCkwOCGzPo=.9aba1fa4-7606-4dda-b29b-1d5db34ccc5b@github.com>

On Fri, 21 Mar 2025 21:25:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:
> 
>> 757: + (BOOL)canStartNestedEventLoop
>> 758: {
>> 759:     return nestedRunLoopRunCount <= 250;
> 
> would it be possible to determine the source of this limit - a header perhaps?
> could it be dependent on os version?

I have not been able to find any header detailing this limit. My guess is that someone at Apple decided to add an internal check for infinite recursion to ensure the app fails early with a clear message and decided 255 levels of nesting should be enough for anyone. The crash log contains these lines (which also show up in the debugger):

> Application Specific Information:
> Too many nested CFRunLoopRuns

The check is new with macOS 15. I tested some standalone code on macOS 13 and 14 and had no problem reaching a nesting level of 500. But I don't think we should make the JavaFX check conditional on OS version number; I wouldn't want a JavaFX app that worked on macOS 14 to fail mysteriously on macOS 15.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2008829542

From mfox at openjdk.org  Sat Mar 22 18:12:10 2025
From: mfox at openjdk.org (Martin Fox)
Date: Sat, 22 Mar 2025 18:12:10 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <2IOCpBrhi-gFX3MtnnD8XzAnB3D5sJAeyYKr8GQOSnQ=.1f6e18a4-4658-45be-bf15-b241233b51c8@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <2IOCpBrhi-gFX3MtnnD8XzAnB3D5sJAeyYKr8GQOSnQ=.1f6e18a4-4658-45be-bf15-b241233b51c8@github.com>
Message-ID: <sxr_qHg7x6Waq7-PNkbvjHNbzAiaimJZg3NMdTEM6N0=.f9c42a4e-ac7d-4386-a838-30a36c135100@github.com>

On Sat, 22 Mar 2025 02:12:48 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> It is better to use dynamically calculated safe limit instead of a hardcoded value like 250.

The problem doesn't seem to be resource exhaustion. It seems that Apple is using a hard-coded number specifically to detect a potential case of infinite CFRunLoop recursion and fail early with a clear message rather than let the app run wild. This doesn't seem to be tied to any limit I can check dynamically.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2745395009

From mstrauss at openjdk.org  Sun Mar 23 08:46:55 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 08:46:55 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v57]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <_rcRL79Rs4fmp8RXVrqjijoMPnr-NSyDN3Ry9beJre4=.667d6f60-ebc4-4fe6-bf1f-ec751feb7183@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  tweak header button scaling at 100%

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/30eb29b7..f8704937

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=56
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=55-56

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From mstrauss at openjdk.org  Sun Mar 23 08:59:22 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 08:59:22 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v45]
In-Reply-To: <wUu2y8YZJbSb6hHXaeYWhxOIsyh0F0WezUD8VFMotlA=.70ec08bf-e621-438d-ac15-b90adaafbd0f@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <KW-gHxcB46OHWN8eMe5ppO-oNCNZIBnJ-kZZU3CNipo=.cd8606f5-be2d-4ed9-a68f-fb725882dd6f@github.com>
 <XL1mupinSJEZe3jyiOZeOc2s1RknlBOtLV14KGYC6WM=.e39e87fd-c88d-4157-846d-9348bcb1d88b@github.com>
 <t8I0A1KQcART0fSaALGi51cUYAlgOui1eBl-M81ud08=.862703b4-4b8e-4b3c-9a7c-a13caa633781@github.com>
 <wUu2y8YZJbSb6hHXaeYWhxOIsyh0F0WezUD8VFMotlA=.70ec08bf-e621-438d-ac15-b90adaafbd0f@github.com>
Message-ID: <-G3RlFfLfEGe3fMn4BhEVSSHmbErM9ssYVMd6da93hE=.17a4698e-6f8f-4908-9d98-d3e6d9fe0cc4@github.com>

On Tue, 4 Feb 2025 12:59:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> It's a bit more than just a generic handler, it basically encapsulates the entire behavior of a window button (including setting its visibility and disabled states).
>
> We generally use "Behavior" in the context of controls. Although not wrong, I also think another name might be better. Maybe "Controller"? Or "Manager"? Or ...

After contemplating for a while, I still think that "Behavior" is the best name. Not that it matters all that much, since it isn't public API.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2009052415

From mstrauss at openjdk.org  Sun Mar 23 08:59:23 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 08:59:23 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v22]
In-Reply-To: <RgIxKWTrtiTR_S_2aLbu24Y_9Rbg4I82CAwi_5NLFKQ=.99108c47-d446-43b0-a2b9-2f6e591f2898@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <Je6WsW7wtat_sayZ_sZdYoo9_ZQUEPu6wlqWCqyi_CA=.ad7392f3-6427-470f-bdbd-6d54b293ae3c@github.com>
 <RgIxKWTrtiTR_S_2aLbu24Y_9Rbg4I82CAwi_5NLFKQ=.99108c47-d446-43b0-a2b9-2f6e591f2898@github.com>
Message-ID: <76B6T_ifYsQB3qIteO05wQwPOTN2PpDC2J3ljWOTAgg=.7f32bc50-00bc-4e33-b389-8329055e8676@github.com>

On Tue, 5 Nov 2024 23:00:36 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - HeaderBar changes
>>  - EMPTY Dimension2D constant
>>  - use CsvSource in HeaderBarTest
>
> modules/javafx.graphics/src/test/java/test/javafx/scene/layout/HeaderBarTest.java line 237:
> 
>> 235:         "BOTTOM_RIGHT, 740, 40, 100, 50"
>> 236:     })
>> 237:     void alignmentOfCenterChild_notResizable_withNonEmptyLeadingAndTrailingChild(
> 
> minor suggestion:
> 
> long test names do not help much (and actually may cause problems, see https://bugs.openjdk.org/browse/JDK-8334497)
> 
> also rather inconvenient to see in the logs, or IDEs.  You can use comments for human-readability and short(er) method names.

I've thought about it for a bit, and decided to leave it as-is for this class.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2009051894

From mstrauss at openjdk.org  Sun Mar 23 09:13:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:13:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v49]
In-Reply-To: <1gCLAZmFlVtGLqR6BQBkLXp_FmxSXSVyLX8kdiPz8g4=.1cf10656-6621-44c0-99f0-bc751c549756@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <rb3OZP_jum88KkMdDmEj_wWStePHQvaRAzT_zmPkGpo=.4295c277-a6fb-46d7-a9d8-e8710b088fad@github.com>
 <cbcgKChaxhas_kWxU1AHaGejk8eAv9mBv59s168YuZw=.5c8694f3-0ad8-422c-a811-781feda336b0@github.com>
 <mPPh0SiEvVQXhiAqELq4dP_obRC79-PyM8QuNaoOl24=.4b58ea6d-c553-435f-8781-9b336188b5ee@github.com>
 <M1cv-ck4DEcs_cfj_T7X9KTy9wCxYyt8gqC4sj77sq8=.32ddf0c2-02fb-4e99-9d89-c6de40eda5e6@github.com>
 <L6-S32srGi--A2G1F3lWC1VeFqJ9G_w2nOtFX0Z5kAA=.5f62532f-f420-4081-a140-d81b96d5c445@github.com>
 <1gCLAZmFlVtGLqR6BQBkLXp_FmxSXSVyLX8kdiPz8g4=.1cf10656-6621-44c0-99f0-bc751c549756@github.com>
Message-ID: <5XdkEZWZ3Y6yg666PtLVBiDzWoZw2_5s64LxI5ePqHU=.b919498f-3178-4842-995b-fe76421034fa@github.com>

On Tue, 18 Feb 2025 20:16:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Are we talking about the specification of the system-reserved insets in `HeaderBar`? Or do you suggest to link from `HeaderButtonMetrics` to `HeaderBar`?
>> 
>> 
>>     /**
>>      * Describes the size of the left system-reserved inset, which is an area reserved for the iconify, maximize,
>>      * and close window buttons. If there are no window buttons on the left side of the window, the returned area
>>      * is an empty {@code Dimension2D}.
>>      * <p>
>>      * Note that the left system inset refers to the left side of the window, independent of layout orientation.
>>      */
>>     private final ReadOnlyObjectWrapper<Dimension2D> leftSystemInset =
>
> a link would be nice, yes (for javafx developers) :-)
> 
> it could be just me - the word "inset" confused me ("insets" -> `Insets`, "inset" -> `Dimension2D`), but I guess it does describe the concept correctly.

Added some links.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2009054464

From mstrauss at openjdk.org  Sun Mar 23 09:13:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:13:04 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v58]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <GXxNgneUeki-cnwdz_DUutYI5dQr7c4J5Hg8y_HsLXU=.d9d3218b-021e-41b6-aaf7-540908e46eac@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  documentation

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/f8704937..a2b5df12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=57
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=56-57

  Stats: 9 lines in 2 files changed: 9 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From mstrauss at openjdk.org  Sun Mar 23 09:13:05 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:13:05 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v49]
In-Reply-To: <HVyfd3AKiybaZZ_8sfJYlVVCBeAkBDqTJ4yv5LaJSx8=.27f5c1d9-023d-4d4d-b40d-5dc1f7bd9443@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <rb3OZP_jum88KkMdDmEj_wWStePHQvaRAzT_zmPkGpo=.4295c277-a6fb-46d7-a9d8-e8710b088fad@github.com>
 <cbcgKChaxhas_kWxU1AHaGejk8eAv9mBv59s168YuZw=.5c8694f3-0ad8-422c-a811-781feda336b0@github.com>
 <mPPh0SiEvVQXhiAqELq4dP_obRC79-PyM8QuNaoOl24=.4b58ea6d-c553-435f-8781-9b336188b5ee@github.com>
 <M1cv-ck4DEcs_cfj_T7X9KTy9wCxYyt8gqC4sj77sq8=.32ddf0c2-02fb-4e99-9d89-c6de40eda5e6@github.com>
 <oGsfP3JZJDg7kIb9LjLkjl60Nm-jAi1CSRDByYZzIms=.7ad99f01-6b28-4d06-9076-7ab0c169e671@github.com>
 <ROYb1YT66_jlSwVFsCNhJJ9DfqPa7iZfT6PaWrrm_6E=.8c2fdaa2-1354-4cf2-9bb4-0536b18f3dc7@github.com>
 <1w_cPPX4G9JhHRGzNIdfFKR0MnEOw8Ldsjyix9M-Slc=.b52be0f3-310b-46b6-9507-267acb42bbb3@github.com>
 <Qp1wopbnU0WAQns8e2V0FW8VJk1UMceLCyKntRPnl8w=.22ae14c2-a7ba-4fda-b22f-c6dca4deb04a@github.com>
 <S4agREsO7Y1l1leIZVs6by9lSmZcuop_SEi3D4tnyuQ=.503387f7-61bf-461e-ad49-6fe9a7f6ad5c@github.com>
 <HVyfd3AKiybaZZ_8sfJYlVVCBeAkBDqTJ4y
 v5LaJSx8=.27f5c1d9-023d-4d4d-b40d-5dc1f7bd9443@github.com>
Message-ID: <ZNC8jdXr9CHYIpebcOzJo6ifv8wqmRT1JZYF8TxmZ0A=.361a892a-9cff-4117-b2b9-e6d4df816a23@github.com>

On Tue, 18 Feb 2025 20:47:24 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> It's a bit like using deep reflection to access internals. It's technically possible, but explicitly unsupported. Much in the same way, any attempt to style header buttons can stop working at any time (because we're free to change the implementation in any way without prior notice). If we were to even mention the internal structure of `HeaderButtonOverlay`, we'd sign up for all of the compatibility guarantees that users expect from public API.
>
> got it, thanks!
> maybe add a not pointing to the css where the styles are being defined?

I added an implementation note.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2009054424

From mstrauss at openjdk.org  Sun Mar 23 09:13:04 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:13:04 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v56]
In-Reply-To: <pS95TaFdfvBY1FjBr0jpoUwR129YoUxoGtKkR4G1bmQ=.dee90563-c9db-40e6-8b18-e40d14daa755@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <nV5wCqJmGNPgZHAzktLkkyIttXEbH1zKVVd9lCuQsyA=.d1c8244b-f03e-4e2e-8d7e-adf0b9fe00cc@github.com>
 <pS95TaFdfvBY1FjBr0jpoUwR129YoUxoGtKkR4G1bmQ=.dee90563-c9db-40e6-8b18-e40d14daa755@github.com>
Message-ID: <9jWgjtyfRHQ0iVSay2lDZbzANuB8KHsITeuJrUnAQQI=.89218e82-51e0-45ef-99aa-263154e950c1@github.com>

On Tue, 18 Mar 2025 21:36:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Standard windows buttons appear blurry and smaller at 100% scale:

I've tweaked the scaling a bit, should be fixed.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1605#issuecomment-2746104110

From mstrauss at openjdk.org  Sun Mar 23 09:13:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:13:07 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v49]
In-Reply-To: <cbcgKChaxhas_kWxU1AHaGejk8eAv9mBv59s168YuZw=.5c8694f3-0ad8-422c-a811-781feda336b0@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <rb3OZP_jum88KkMdDmEj_wWStePHQvaRAzT_zmPkGpo=.4295c277-a6fb-46d7-a9d8-e8710b088fad@github.com>
 <cbcgKChaxhas_kWxU1AHaGejk8eAv9mBv59s168YuZw=.5c8694f3-0ad8-422c-a811-781feda336b0@github.com>
Message-ID: <JCIIqCW6oF7hghTZjBYiEtBtIrUz9QiwncCZo6DEMdk=.861b600e-e938-479f-9390-6d968007f84d@github.com>

On Fri, 14 Feb 2025 17:22:03 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - typo
>>  - update copyright headers
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/HeaderButtonOverlay.java line 678:
> 
>> 676:             orderedButtons.add(this);
>> 677:             buttonOrder.set(order);
>> 678:             glyph.getStyleClass().setAll("glyph");
> 
> "glyph": though apt, the name might be somewhat confusing.  maybe "icon"?

I considered "icon", but still think that "glyph" captures the meaning a tiny bit better.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1605#discussion_r2009054216

From mstrauss at openjdk.org  Sun Mar 23 09:21:06 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 23 Mar 2025 09:21:06 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v59]
In-Reply-To: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
Message-ID: <rODUnW5oS3iOFFi4WH8UjLZ0jQkfORDjZVR35_v-H9A=.45491376-9d5e-4d33-8ba6-a358dc7b7f03@github.com>

> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  documentation

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1605/files
  - new: https://git.openjdk.org/jfx/pull/1605/files/a2b5df12..50f9c75a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=58
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1605&range=57-58

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1605/head:pull/1605

PR: https://git.openjdk.org/jfx/pull/1605

From arapte at openjdk.org  Mon Mar 24 07:59:29 2025
From: arapte at openjdk.org (Ambarish Rapte)
Date: Mon, 24 Mar 2025 07:59:29 GMT
Subject: RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <ZRXVGg-1YS76YaQ7rE_g-lWY6U7K8dsmwNkxIHKGHSo=.c7f75346-a576-4b20-9fc9-8c6a5612818b@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

The CanvasTest fails before and passes after this change. LGTM

-------------

Marked as reviewed by arapte (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1740#pullrequestreview-2709462725

From jbhaskar at openjdk.org  Mon Mar 24 09:06:29 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 24 Mar 2025 09:06:29 GMT
Subject: Integrated: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
In-Reply-To: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
References: <nDdZYTZ1At7ty-_3TsLR3IowqohYYS-nFUPyDA5W_Uw=.915ad575-b9bc-4787-b5d2-914d7ad5517c@github.com>
Message-ID: <0onYiyP4v6ZRKMd1KbM0a5snQMFYAgex3nEBpfRJNR8=.076d8da9-6e46-4af6-bf2a-e93d9f462a50@github.com>

On Fri, 21 Mar 2025 08:17:39 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> Issue: 
> Ref: Webkit 619.1 javafx.web/src/main/native/Source/WebCore/platform/graphics/ImageSource.cpp refactoring in 620.1
> In the case of the canvas pattern using a transform property filled with an SVGMatrix()
> created by an SVG element, `frame.m_nativeImage->size()` calls `NativeImage::size()`
> from NativeImageJava.cpp. In this scenario, `*m_platformImage->getImage().get()` may be invalid,
> as the image decoder has already populated `frame.m_size` during image metadata caching.
> 
> Solution:
> To avoid potential invalid accesses and unintended size resets, only update `m_size`
> if the frame does not already have a valid native image.

This pull request has now been integrated.

Changeset: fd099a7f
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/fd099a7f067c1694c1c12a8fa02b1e7eda51201f
Stats:     20 lines in 2 files changed: 18 ins; 2 del; 0 mod

8347937: Canvas pattern test fails and crashes on WebKit 620.1

Co-authored-by: Gopal Pattnaik <gopal.pattnaik at oracle.com>
Reviewed-by: kcr, arapte

-------------

PR: https://git.openjdk.org/jfx/pull/1740

From lkostyra at openjdk.org  Mon Mar 24 09:16:18 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 24 Mar 2025 09:16:18 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4]
In-Reply-To: <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <zfUIlWadRmSXrqKGMS5l50jk6VrnUEX0z-M0BGvHitw=.00d0a79f-6573-434d-831f-9f21f920e432@github.com>
 <QGwYk-SfbbYOJouHxTePyVnmwvZX6x9knmSIzbJq-v8=.234a94c3-8916-425c-a52d-77ef5542c0b7@github.com>
 <wQ6ydnTeXl4qbuoVxZPlDdSV5US-WpkKrcbSjL6w3zE=.5ce2312d-78df-4b75-bd44-1d79a87cfb6a@github.com>
 <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
Message-ID: <YUf4Q7x3q2pltWVCIyth0qAvZv8-S9JcH_k3CKbH6wg=.c0a185a3-fed4-4e6d-800b-12c8dbcbc3ae@github.com>

On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> As the existing code was already pretty optimistic about 2 byte chars, is it possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT is just tried first.
>
> Could be, but in any case, the way it's impemented right now doesn't seem to be right. We should only assume 2-byte characters if what's being pulled from the clipboard is actually `CF_UNICODETEXT`.

I did a little bit of digging and we will sometimes request `CF_TEXT` and `CF_OEMTEXT` (see `create_mime_stuff()` in this file). Technically we could change the pairings there and always request text data in `CF_UNICODETEXT`, but I would do some more testing and check if that doesn't cause regressions in some surprise spot.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2009765278

From lkostyra at openjdk.org  Mon Mar 24 10:18:13 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Mon, 24 Mar 2025 10:18:13 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <Jw0jdxVHRcLG0HM5x13dwMpKzY7liaSazcrEYqXhL8k=.0118a24a-f466-4d24-b0bf-4ad48981c2ba@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

Looks good, verified on Windows 11 - test fails without fix and works with it.

-------------

Marked as reviewed by lkostyra (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1727#pullrequestreview-2709843635

From jbhaskar at openjdk.org  Mon Mar 24 12:58:35 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 24 Mar 2025 12:58:35 GMT
Subject: [jfx24u] RFR: 8347937: Canvas pattern test fails and crashes on WebKit
 620.1
Message-ID: <uJej5zYzmcgzfO5Ivx7g02wzXDJJcR_gGSyiWCqw0EY=.c8790923-fa92-4591-a190-f3522767ea02@github.com>

A clean backport to jfx24u , the patch fixes current canvas pattern issue where canvas pattern drawing was not working when using svg matrix image.

-------------

Commit messages:
 - Backport fd099a7f067c1694c1c12a8fa02b1e7eda51201f

Changes: https://git.openjdk.org/jfx24u/pull/16/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx24u&pr=16&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347937
  Stats: 20 lines in 2 files changed: 18 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx24u/pull/16.diff
  Fetch: git fetch https://git.openjdk.org/jfx24u.git pull/16/head:pull/16

PR: https://git.openjdk.org/jfx24u/pull/16

From zelmidaoui at openjdk.org  Mon Mar 24 13:15:19 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 24 Mar 2025 13:15:19 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v2]
In-Reply-To: <ILtZzj3UOyf_eBFIMgYcTha3baLn-OY6pWDIMeVJESc=.9646501e-5d7e-4d0f-b378-df317d742a0d@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <Ieb_X7SRc5_KUnwT_LCZlJoU_P9eJIxtF8FFmIQwi_I=.2ab842aa-413d-4243-9ab4-2b32b191c9a2@github.com>
 <vB89NAhNgUAMbiGRorN4Q-vC3hJTmS0PnAmysgQ8KRg=.7292d909-b917-4b61-ad96-b7e6d226b516@github.com>
 <ILtZzj3UOyf_eBFIMgYcTha3baLn-OY6pWDIMeVJESc=.9646501e-5d7e-4d0f-b378-df317d742a0d@github.com>
Message-ID: <Lwxfq02x6JK-cM0ldmFO1z0DJZia08xq7r5irqvX9kM=.0c1bdcf0-e0b3-4429-b46c-a427be9497ee@github.com>

On Fri, 21 Mar 2025 06:00:12 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> You should consider using a fluent binding here, which is a more modern solution compared to the `Bindings` class. It is also simpler because you don't need to check for `null`:
>> 
>> 
>> promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));
>
> Have you considered the suggestion?

Yes I will push the new changes thanks for the suggestion @mstr2

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2010157516

From jbhaskar at openjdk.org  Mon Mar 24 13:43:14 2025
From: jbhaskar at openjdk.org (Jay Bhaskar)
Date: Mon, 24 Mar 2025 13:43:14 GMT
Subject: [jfx24u] Integrated: 8347937: Canvas pattern test fails and crashes on
 WebKit 620.1
In-Reply-To: <uJej5zYzmcgzfO5Ivx7g02wzXDJJcR_gGSyiWCqw0EY=.c8790923-fa92-4591-a190-f3522767ea02@github.com>
References: <uJej5zYzmcgzfO5Ivx7g02wzXDJJcR_gGSyiWCqw0EY=.c8790923-fa92-4591-a190-f3522767ea02@github.com>
Message-ID: <EqbQrGPqSnsAlunaIWc8A7UgofvgDF9O3g4uIus3EBA=.921e2afb-be7b-4cf1-8a25-e3db50a06750@github.com>

On Mon, 24 Mar 2025 12:52:42 GMT, Jay Bhaskar <jbhaskar at openjdk.org> wrote:

> A clean backport to jfx24u , the patch fixes current canvas pattern issue where canvas pattern drawing was not working when using svg matrix image.

This pull request has now been integrated.

Changeset: 1ea359be
Author:    Jay Bhaskar <jbhaskar at openjdk.org>
URL:       https://git.openjdk.org/jfx24u/commit/1ea359be8744f06ff2d6a0fe62f8f8acc50c522e
Stats:     20 lines in 2 files changed: 18 ins; 2 del; 0 mod

8347937: Canvas pattern test fails and crashes on WebKit 620.1

Backport-of: fd099a7f067c1694c1c12a8fa02b1e7eda51201f

-------------

PR: https://git.openjdk.org/jfx24u/pull/16

From zelmidaoui at openjdk.org  Mon Mar 24 14:23:39 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 24 Mar 2025 14:23:39 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v3]
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <PunjkpgbPCkslbyjAOVVicfp3I2ht1EACldtcbc1E0g=.8a759507-f43e-4752-b62f-a090fa8025e9@github.com>

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Minor changes

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1716/files
  - new: https://git.openjdk.org/jfx/pull/1716/files/68b0c868..549c1997

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1716.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1716/head:pull/1716

PR: https://git.openjdk.org/jfx/pull/1716

From angorya at openjdk.org  Mon Mar 24 15:07:24 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 15:07:24 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <XdHfPekSWUrr6tQt4a1ZcYzMxVhGvsXyJqVko3fJIgk=.52c4eaa3-1464-4f36-980c-e9d27f9f9392@github.com>

On Fri, 21 Mar 2025 20:56:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

I think the proposed solution is a good one.  Creating over 250 nested loops seems like a design mistake to me - why would anyone want to create that many event loops?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2748445110

From crschnick at xpipe.io  Mon Mar 24 15:21:57 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Mon, 24 Mar 2025 16:21:57 +0100
Subject: IndexOutOfBoundsException in Parent::updateCachedBounds when
 visibility changes
Message-ID: <e236b328-024f-4ca8-af18-19d891c4bd8b@xpipe.io>

Hello,

We encountered an issue after updating our application implementation to 
frequently change the visibility of nodes. We are essentially now 
running an implementation that very frequently changes the visibility of 
various children nodes based on when they are needed and shown. When the 
user performs a lot of actions, the visibility of many nodes will be 
changed rapidly.

For that, there are many listeners in place that listen for bounds 
changes of nodes to recheck whether they need to be made visible or not. 
All the visibility changes are queued up, so they are not immediately 
done in the listener after any bounds changes of parents. They are all 
properly done on the platform thread with runLater. When this 
implementation is running on many client systems, we sometimes receive 
an error report with an exception that looks something like this:

java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
 ??? at 
java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
 ??? at 
java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
 ??? at 
java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
 ??? at java.base/java.util.Objects.checkIndex(Objects.java:365)
 ??? at java.base/java.util.ArrayList.get(ArrayList.java:428)
 ??? at 
javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
 ??? at 
javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
 ??? at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
 ??? at 
javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
 ??? at 
javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
 ??? at 
javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
 ??? at 
javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)

The index out of bounds is not always the same, there are various 
variations of this. It happens on all operating systems. It seems like 
there is a very specific scenario where an index can be out of bounds. 
This happens very rarely, like only a few times out of some hundred 
application runs, so I tried my best at forcing it to reproduce.

The following reproducer works most of the time, but it might have to be 
run multiple times. I am aware that it eventually results in a 
StackOverflow, but that was the best way to force it reliably, by just 
continuously spamming visibility changes to eventually encounter this 
rare issue. But I want to emphasize that the same error also occurs 
naturally when not being forced like this, but it is just a lot more 
rare. So the StackOverflow in the reproducer has nothing to do with this 
issue, it also happens later on.

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.Region;
import javafx.scene.layout.StackPane;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

import java.io.IOException;

public class ParentBoundsBugextends Application {

     @Override public void start(Stage stage)throws IOException {
         Scene scene =new Scene(createContent(),640,480);
         stage.setScene(scene);
         stage.show();
         stage.centerOnScreen();
     }

     private RegioncreateContent() {
         var b1 =new Button("Click me!");
         var b2 =new Button("Click me!");
         var vbox =new VBox(b1, b2);
         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });

         var stack =new StackPane(vbox,new StackPane());
         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         return stack;
     }

     public static void main(String[] args) {
         launch();
     }
}


It doesn't necessarily have something to do with running the visibility 
change directly in the listener, our application does a runLater to 
change the visibility state, still with the same results. To properly 
debug this, you will have to launch the reproducer with a bigger stack 
size like -Xss8m to increase the chance that it occurs. Then, you can 
just set a breakpoint at jdk.internal.util.Preconditions:302, and wait 
for it to trigger the OOB eventually.

This problem is currently the biggest JavaFX issue for us as it breaks 
the layout and usually requires a restart to fix.

Looking at the bounds calculation code, the list index bounds check is 
very optimistic in that it doesn't check any indices and relies on 
multiple assumtions to hold. So if it is very difficult to find the 
cause, a simple index bounds check for the list access would also work fine.

Best
Christopher Schnick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250324/22887cd5/attachment-0001.htm>

From mfox at openjdk.org  Mon Mar 24 15:30:33 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 15:30:33 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Added explanation for limit on nested run loop calls

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/02913fe2..49a21b48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=00-01

  Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From angorya at openjdk.org  Mon Mar 24 15:34:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 15:34:21 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
Message-ID: <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>

On Mon, 24 Mar 2025 15:30:33 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added explanation for limit on nested run loop calls

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 637:

> 635:         if (!canStartNestedEventLoop()) {
> 636:             if (!Application.GetApplication().canStartNestedEventLoop()) {
> 637:                 throw new RuntimeException("Exceeded limit on nested event loops");

should we tell what the limit is (using the static constant mentioned earlier)?
e.g.
"Too many nested event loops (250)"? or something like that.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010377313

From angorya at openjdk.org  Mon Mar 24 15:34:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 15:34:22 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <NlQ4JY-TACw7xWsVSavvx7RkdFP2r2hYANCkwOCGzPo=.9aba1fa4-7606-4dda-b29b-1d5db34ccc5b@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <9stOE4xTqbFLV_KH2mkSXZKrV8gjlADzARGmz9KSSWM=.566c1a54-c70e-4da9-b153-6573c87793b3@github.com>
 <NlQ4JY-TACw7xWsVSavvx7RkdFP2r2hYANCkwOCGzPo=.9aba1fa4-7606-4dda-b29b-1d5db34ccc5b@github.com>
Message-ID: <0EmidRom6ZtGNxiAoMa8e4wi_ajdJFutl1JdRqEsRQI=.d3f8c985-bb0b-49df-9c1b-e89b2934b050@github.com>

On Sat, 22 Mar 2025 18:05:13 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:
>> 
>>> 757: + (BOOL)canStartNestedEventLoop
>>> 758: {
>>> 759:     return nestedRunLoopRunCount <= 250;
>> 
>> would it be possible to determine the source of this limit - a header perhaps?
>> could it be dependent on os version?
>
> I have not been able to find any header detailing this limit. My guess is that someone at Apple decided to add an internal check for infinite recursion to ensure the app fails early with a clear message and decided 255 levels of nesting should be enough for anyone. The crash log contains these lines (which also show up in the debugger):
> 
>> Application Specific Information:
>> Too many nested CFRunLoopRuns
> 
> The check is new with macOS 15. I tested some standalone code on macOS 13 and 14 and had no problem reaching a nesting level of 500. But I don't think we should make the JavaFX check conditional on OS version number; I wouldn't want a JavaFX app that worked on macOS 14 to fail mysteriously on macOS 15.

I second Kevin's suggestion to add a constant with a good comment, since it's an arbitrarily chosen limit.  It would explain the "why" if/when the things change in macOS.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010372776

From mfox at openjdk.org  Mon Mar 24 15:47:28 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 15:47:28 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <EVwMizWIThGitrmaHupuj706szC0gf7uzA9tw4BLtcU=.62d69cbc-addf-46e1-ba2e-2993e96d44d7@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <EVwMizWIThGitrmaHupuj706szC0gf7uzA9tw4BLtcU=.62d69cbc-addf-46e1-ba2e-2993e96d44d7@github.com>
Message-ID: <3Bml9bDNsVpbUpqjuuWDirDrcEMrDFJDm1mzQpPrAV0=.be192d45-b4ad-42c1-97f1-1681c55e4a1d@github.com>

On Fri, 21 Mar 2025 21:15:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added explanation for limit on nested run loop calls
>
> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:
> 
>> 757: + (BOOL)canStartNestedEventLoop
>> 758: {
>> 759:     return nestedRunLoopRunCount <= 250;
> 
> How sure are you that 250 is a safe limit? Are there situations where we might not be able to do this many?
> 
> I recommend added a comment as to where the magic number "250" comes from. And maybe put it in a static const variable?

I added a comment explaining where the number comes from. Since it's only used in this one spot putting it in a static const variable seemed redundant.

I'm not sure that 250 is a safe limit. I know that the JUnit test crashes if this value is set to 252 but succeeds at 251. I don't want to risk disturbing existing apps but since each count represents a runnable waiting for an event loop to exit even 200 seems like a high number. It might be prudent to set this to, say, 246 to give us a bit more headroom.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010442538

From angorya at openjdk.org  Mon Mar 24 17:02:31 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 17:02:31 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v3]
In-Reply-To: <PunjkpgbPCkslbyjAOVVicfp3I2ht1EACldtcbc1E0g=.8a759507-f43e-4752-b62f-a090fa8025e9@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <PunjkpgbPCkslbyjAOVVicfp3I2ht1EACldtcbc1E0g=.8a759507-f43e-4752-b62f-a090fa8025e9@github.com>
Message-ID: <gdZH3kUGnukYfzHoLDa6jUV43U2GFMOpwoo6Z2ihe3Q=.659c2a73-2d6c-46c3-98ae-bdbf275f710a@github.com>

On Mon, 24 Mar 2025 14:23:39 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor changes

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 33:

> 31: import javafx.beans.binding.ObjectBinding;
> 32: import javafx.beans.binding.StringBinding;
> 33: import javafx.beans.binding.Bindings;

unused import can be removed

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 737:

> 735: 
> 736:         promptNode.textProperty().bind(getSkinnable().promptTextProperty());
> 737:         promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));

code in line 736 is not needed (we all missed that)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2010589070
PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2010583781

From mfox at openjdk.org  Mon Mar 24 17:38:13 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 17:38:13 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
Message-ID: <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>

On Mon, 24 Mar 2025 15:09:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added explanation for limit on nested run loop calls
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 637:
> 
>> 635:         if (!canStartNestedEventLoop()) {
>> 636:             if (!Application.GetApplication().canStartNestedEventLoop()) {
>> 637:                 throw new RuntimeException("Exceeded limit on nested event loops");
> 
> should we tell what the limit is (using the static constant mentioned earlier)?
> e.g.
> "Too many nested event loops (250)"? or something like that.

The number is in the Mac-only Glass code and may change over time so it would be a maintenance burden to repeat it here. But if a developer does see this exception I'm sure their first question would be what the limit is. I can update the comment with something vague (like "over > 240") but I'm hoping that the very, very long Java stack trace attached to this exception will be enough.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010647914

From kcr at openjdk.org  Mon Mar 24 17:54:20 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 17:54:20 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
 <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
Message-ID: <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>

On Mon, 24 Mar 2025 17:35:46 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/QuantumToolkit.java line 637:
>> 
>>> 635:         if (!canStartNestedEventLoop()) {
>>> 636:             if (!Application.GetApplication().canStartNestedEventLoop()) {
>>> 637:                 throw new RuntimeException("Exceeded limit on nested event loops");
>> 
>> should we tell what the limit is (using the static constant mentioned earlier)?
>> e.g.
>> "Too many nested event loops (250)"? or something like that.
>
> The number is in the Mac-only Glass code and may change over time so it would be a maintenance burden to repeat it here. But if a developer does see this exception I'm sure their first question would be what the limit is. I can update the comment with something vague (like "over > 240") but I'm hoping that the very, very long Java stack trace attached to this exception will be enough.

Unless you are going to track the actual depth, I'd probably leave it as is. When Java throws a StackOverflow it doesn't print the depth.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010671459

From kcr at openjdk.org  Mon Mar 24 17:54:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 17:54:21 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v2]
In-Reply-To: <3Bml9bDNsVpbUpqjuuWDirDrcEMrDFJDm1mzQpPrAV0=.be192d45-b4ad-42c1-97f1-1681c55e4a1d@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <EVwMizWIThGitrmaHupuj706szC0gf7uzA9tw4BLtcU=.62d69cbc-addf-46e1-ba2e-2993e96d44d7@github.com>
 <3Bml9bDNsVpbUpqjuuWDirDrcEMrDFJDm1mzQpPrAV0=.be192d45-b4ad-42c1-97f1-1681c55e4a1d@github.com>
Message-ID: <kdlKDLVBHhzJaY1XXwmK_IictCVq-XCWU-h5d2Kd-Uo=.22f8f1e0-2c36-458a-9194-bb78bc025b5c@github.com>

On Mon, 24 Mar 2025 15:44:30 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/mac/GlassApplication.m line 759:
>> 
>>> 757: + (BOOL)canStartNestedEventLoop
>>> 758: {
>>> 759:     return nestedRunLoopRunCount <= 250;
>> 
>> How sure are you that 250 is a safe limit? Are there situations where we might not be able to do this many?
>> 
>> I recommend added a comment as to where the magic number "250" comes from. And maybe put it in a static const variable?
>
> I added a comment explaining where the number comes from. Since it's only used in this one spot putting it in a static const variable seemed redundant.
> 
> I'm not sure that 250 is a safe limit. I know that the JUnit test crashes if this value is set to 252 but succeeds at 251. I don't want to risk disturbing existing apps but since each count represents a runnable waiting for an event loop to exit even 200 seems like a high number. It might be prudent to set this to, say, 246 to give us a bit more headroom.

I agree that it might be wise to set it a bit lower, so either 246 or even 240 seems reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010666441

From kcr at openjdk.org  Mon Mar 24 18:18:26 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 18:18:26 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <deh97ZYO0DOBR6bbX_rLUGjiEEVjaje2fcd7g2PvGRc=.2edb8768-b46c-4744-80da-6d4ea5d9f146@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

The changes look correct to me as does my testing. I left a minor question or two, but nothing that needs to be addressed before integration.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1723#pullrequestreview-2711271059

From kcr at openjdk.org  Mon Mar 24 18:18:27 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 18:18:27 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <tPwoPglueG7jL8BJFOhqHquZS52RxnQS4jjjhLlSG6c=.23ca6a11-c60b-4140-bd9c-ff7bad0d818d@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
 <wUV1kso66uEzarkxK2ksRTq983TvKCYuYvd-xVWmh1A=.6c6d3698-c9e3-451c-9ccb-f05e56721a34@github.com>
 <XvBbgp_KcLnHikIdb4zR4iM4qmvUUcH8myPI50BcazU=.4021a2b9-4f4e-4b3e-8c98-43d13179e0c4@github.com>
 <HL3CMERGmNGZ8gkkuqNpL-t_RdskhVNqkKuVOanUsXc=.a3b21898-d356-4e48-bec3-a853abb24a25@github.com>
 <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com>
 <gmfRPkkXNNcqun5AiLgl4bq1ib8phUnh4haqrNnmOSw=.4e999851-e7e8-4075-9398-ffec7028c2e5@github.com>
 <tf4l_YxIicp8HX2VJJbkuWbfFxwdIWKd8RI0ZSVW2kc=.7bd50913-8d90-4fbf-927c-04b1e9790f49@github.com>
 <tPwoPglueG7jL8BJFOhqHquZS52RxnQS4jjjhLlSG6c=.23ca6a11-c60b-4140-bd9c-ff7bad0d818d@github.com>
Message-ID: <JtZeFwHUFCTcJNU0PLekHO9FCAPbFKxf7PPTflY8lF4=.72bca3ca-4a0c-4fa6-92a6-f074747de7cd@github.com>

On Fri, 28 Feb 2025 23:11:45 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>>> good point!
>>> 
>>> This is exactly the reason for the code in ScaledMath:71
>>> 
>>> ```
>>> return Math.ceil(d - Math.ulp(d)) / scale;
>>> ```
>> 
>> Yeah, but I think we may want to subtract more than just 1 ulp.  A one ulp difference can be created after any operation (like add/subtract).  Do two of these without resnapping, and the difference will be >1 ulp)
>
> I think you are onto something here.  It almost feels like we shouldn't be doing ceil/floor at all, rounding to the closest pixel instead.

This would be a much larger change, though. Perhaps something to consider for a future discussion.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010678869

From kcr at openjdk.org  Mon Mar 24 18:18:29 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 18:18:29 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
Message-ID: <FGX24srTC9BOzmAYy2E-oI1j9nOlhENicbUE9eprdx4=.d970206e-a3ed-4ba1-abd6-ae26efef4ce9@github.com>

On Mon, 24 Feb 2025 17:21:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2093:
> 
>> 2091:         double right = margin != null ? snapSpaceX(margin.getRight(), snap) : 0;
>> 2092: 
>> 2093:         return width - left - right;
> 
> snap?

@hjohn You may have answered this question in the larger discussion above, but I wanted to double-check.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010683616

From mfox at openjdk.org  Mon Mar 24 18:30:56 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 18:30:56 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Lower limit on run loop nesting

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/49a21b48..0d44f217

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From mfox at openjdk.org  Mon Mar 24 18:30:56 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 18:30:56 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <kdlKDLVBHhzJaY1XXwmK_IictCVq-XCWU-h5d2Kd-Uo=.22f8f1e0-2c36-458a-9194-bb78bc025b5c@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <EVwMizWIThGitrmaHupuj706szC0gf7uzA9tw4BLtcU=.62d69cbc-addf-46e1-ba2e-2993e96d44d7@github.com>
 <3Bml9bDNsVpbUpqjuuWDirDrcEMrDFJDm1mzQpPrAV0=.be192d45-b4ad-42c1-97f1-1681c55e4a1d@github.com>
 <kdlKDLVBHhzJaY1XXwmK_IictCVq-XCWU-h5d2Kd-Uo=.22f8f1e0-2c36-458a-9194-bb78bc025b5c@github.com>
Message-ID: <1XGPyumZ5p-NVpgrmyMIxuVosOeTkcJbhNuL6e_Orxg=.166d0ed6-680c-4954-a3a4-d0d5310b48e0@github.com>

On Mon, 24 Mar 2025 17:48:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I added a comment explaining where the number comes from. Since it's only used in this one spot putting it in a static const variable seemed redundant.
>> 
>> I'm not sure that 250 is a safe limit. I know that the JUnit test crashes if this value is set to 252 but succeeds at 251. I don't want to risk disturbing existing apps but since each count represents a runnable waiting for an event loop to exit even 200 seems like a high number. It might be prudent to set this to, say, 246 to give us a bit more headroom.
>
> I agree that it might be wise to set it a bit lower, so either 246 or even 240 seems reasonable.

Set to 244 so I didn't have to alter the system test.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010723341

From mfox at openjdk.org  Mon Mar 24 18:46:22 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 18:46:22 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

At the risk of opening a can of worms I ran some manual tests on Linux and Windows. Windows starts behaving erratically when the nesting level goes beyond 280. I've occasionally seen a Java.lang.stackOverflowError but most often it freezes up and then the next click causes it to crash with an access violation. Linux behaves well until it gets beyond 600 and then also starts to freeze up (doesn't seem to crash). I haven't dug into what's going on under the hood.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749090108

From kcr at openjdk.org  Mon Mar 24 19:59:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 19:59:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <F_Gu5IHl6NdvIvel6sxJRhSEluuWyKp1Wp5xxkYsyBs=.f9110823-8d4c-4825-bad0-c78b401d1575@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

The fix and test look good. My local testing shows that it works as expected. I confirm that on macOS 15 the new test crashes before your fix and passes with the fix.

Just to be on the safe side, I fired off a headful CI test run. I'll approve once it passes.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2711533694

From kcr at openjdk.org  Mon Mar 24 19:59:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 19:59:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>
Message-ID: <nMZ6MpYouzXejh3GIlv1vNXQ8yW3qKSsHCL3g8cLux4=.6460a487-8fc5-4a59-80df-ca318a839db6@github.com>

On Mon, 24 Mar 2025 18:43:42 GMT, Martin Fox <mfox at openjdk.org> wrote:

> At the risk of opening a can of worms I ran some manual tests on Linux and Windows. Windows starts behaving erratically when the nesting level goes beyond 280. I've occasionally seen a Java.lang.stackOverflowError but most often it freezes up and then the next click causes it to crash with an access violation. Linux behaves well until it gets beyond 600 and then also starts to freeze up (doesn't seem to crash). I haven't dug into what's going on under the hood.

We might want to consider imposing a limit on Linux and Windows, too. It could probably be done as a follow-up...

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749245036

From kcr at openjdk.org  Mon Mar 24 19:59:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 19:59:17 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <nMZ6MpYouzXejh3GIlv1vNXQ8yW3qKSsHCL3g8cLux4=.6460a487-8fc5-4a59-80df-ca318a839db6@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>
 <nMZ6MpYouzXejh3GIlv1vNXQ8yW3qKSsHCL3g8cLux4=.6460a487-8fc5-4a59-80df-ca318a839db6@github.com>
Message-ID: <259SCh8aKMCAwTMMSV4H-MVWqmQJ6dnhZxJ8H_goznw=.9d322dd2-1ab4-4fd9-82d4-08f3c6eb7868@github.com>

On Mon, 24 Mar 2025 19:54:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> We might want to consider imposing a limit on Linux and Windows, too. It could probably be done as a follow-up...

Although doing it as part of this PR would be OK, too. Which would you prefer?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749247773

From angorya at openjdk.org  Mon Mar 24 19:59:17 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 19:59:17 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
 <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
 <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>
Message-ID: <nR1rD8cWcAH15HiSPuvaQCbskFC9-T3uKAbDEiUCVOY=.3f357da2-ee3c-41e6-8702-c0f9aca2f4a6@github.com>

On Mon, 24 Mar 2025 17:51:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The number is in the Mac-only Glass code and may change over time so it would be a maintenance burden to repeat it here. But if a developer does see this exception I'm sure their first question would be what the limit is. I can update the comment with something vague (like "over > 240") but I'm hoping that the very, very long Java stack trace attached to this exception will be enough.
>
> Unless you are going to track the actual depth, I'd probably leave it as is. When Java throws a StackOverflow it doesn't print the depth.

what I meant is the exception should indicate the limit that triggered the exception.
because it will likely be the first question the application developer asks when seeing this exception.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010841926

From angorya at openjdk.org  Mon Mar 24 20:02:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 20:02:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <mta3JHO0JXvaz9uffsgEYEXyqghb6tHO8V20osK_OY8=.dd7b4b57-a104-4ce0-8218-d04f154a3d82@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

I still not sure why anyone would need to create that many (>200) nested event loops.  So +1 for checking that on win/linux as well, possibly using the same constant (I would like to see a constant, maybe `REASONABLE_NUMBER_OF_NESTED_EVENT_LOOPS` )

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749254584

From mstrauss at openjdk.org  Mon Mar 24 20:08:13 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Mon, 24 Mar 2025 20:08:13 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <nR1rD8cWcAH15HiSPuvaQCbskFC9-T3uKAbDEiUCVOY=.3f357da2-ee3c-41e6-8702-c0f9aca2f4a6@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
 <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
 <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>
 <nR1rD8cWcAH15HiSPuvaQCbskFC9-T3uKAbDEiUCVOY=.3f357da2-ee3c-41e6-8702-c0f9aca2f4a6@github.com>
Message-ID: <f22o07cQzwzQl38ZUanfhSCrR_LlOFsFyJsdObs_ViU=.7e62bc71-be97-45a7-b6e5-1d78dc2f4bde@github.com>

On Mon, 24 Mar 2025 19:56:21 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Unless you are going to track the actual depth, I'd probably leave it as is. When Java throws a StackOverflow it doesn't print the depth.
>
> what I meant is the exception should indicate the limit that triggered the exception.
> because it will likely be the first question the application developer asks when seeing this exception.

The limit is an implementation detail, and should not be elevated to specification. What application developers should be doing if they want to avoid hitting the limit, is call `Platform.canStartNestedEventLoop()`.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010852943

From kcr at openjdk.org  Mon Mar 24 20:11:16 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 20:11:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <CuKna5hL4J_X_Qvb1E6oyK6OKltZwaBxrfNN8mZ41r0=.05a5e2ee-975f-4fe6-91d1-8f6d41cbefa4@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

If we go with the same limit on each platform, which does have some advantages, we might consider documenting that limit in the spec.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749273401

From angorya at openjdk.org  Mon Mar 24 20:14:11 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 20:14:11 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <f22o07cQzwzQl38ZUanfhSCrR_LlOFsFyJsdObs_ViU=.7e62bc71-be97-45a7-b6e5-1d78dc2f4bde@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
 <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
 <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>
 <nR1rD8cWcAH15HiSPuvaQCbskFC9-T3uKAbDEiUCVOY=.3f357da2-ee3c-41e6-8702-c0f9aca2f4a6@github.com>
 <f22o07cQzwzQl38ZUanfhSCrR_LlOFsFyJsdObs_ViU=.7e62bc71-be97-45a7-b6e5-1d78dc2f4bde@github.com>
Message-ID: <OyP_vvxm6o5iNFGSLkiObu6BPHbasScRabPr5luWPng=.3ecc3969-8f0c-4214-8ef7-2376a545fcfc@github.com>

On Mon, 24 Mar 2025 20:05:34 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> what I meant is the exception should indicate the limit that triggered the exception.
>> because it will likely be the first question the application developer asks when seeing this exception.
>
> The limit is an implementation detail, and should not be elevated to specification. What application developers should be doing if they want to avoid hitting the limit, is call `Platform.canStartNestedEventLoop()`.

disagree: we are not codifying what the limit is, but showing the condition at the exception, for the sake of application developers.

`ArrayList.set(int, T)` throws an exception specifying the offending index value.  Not exactly the same situation, but the same spirit.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010860909

From kcr at openjdk.org  Mon Mar 24 20:33:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 20:33:15 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <OyP_vvxm6o5iNFGSLkiObu6BPHbasScRabPr5luWPng=.3ecc3969-8f0c-4214-8ef7-2376a545fcfc@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <cj2kWpDjtpFM3528vMaliHhwCso5BrXTDc6rjnZu1h0=.d11afa3b-5a97-459c-9d0d-8a3e2607505c@github.com>
 <hwk3oris8_lMkkMsJMIy3YlmGvHVh1haGWQbbJcuXMk=.5fe34562-afb2-4504-886f-293fe0083110@github.com>
 <vQcZ50GubGK-t6UVI9IvYPETsBJPJg2uc_-UoCDlsQ8=.4292d9f2-e485-47fa-ad87-9c521de53b0b@github.com>
 <tvKFHnPZdw24qipxAursua-eYxNnNhsBZxACc8BkFcs=.46a2c03a-df2a-4fa9-b291-0dffa6c87869@github.com>
 <nR1rD8cWcAH15HiSPuvaQCbskFC9-T3uKAbDEiUCVOY=.3f357da2-ee3c-41e6-8702-c0f9aca2f4a6@github.com>
 <f22o07cQzwzQl38ZUanfhSCrR_LlOFsFyJsdObs_ViU=.7e62bc71-be97-45a7-b6e5-1d78dc2f4bde@github.com>
 <OyP_vvxm6o5iNFGSLkiObu6BPHbasScRabPr5luWPng=.3ecc3969-8f0c-4214-8ef7-2376a545fcfc@github.com>
Message-ID: <TClTTnMygVFROXqOVoFS8AVN8kqRDc_zc4qQQzB50j8=.b3b7d56f-c630-4455-996f-af7538f9c2ec@github.com>

On Mon, 24 Mar 2025 20:11:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> The limit is an implementation detail, and should not be elevated to specification. What application developers should be doing if they want to avoid hitting the limit, is call `Platform.canStartNestedEventLoop()`.
>
> disagree: we are not codifying what the limit is, but showing the condition at the exception, for the sake of application developers.
> 
> `ArrayList.set(int, T)` throws an exception specifying the offending index value.  Not exactly the same situation, but the same spirit.

This is more like the StackOverflow case where the nesting level has gone too deep. It wouldn't hurt tell the application how deep they are (and from that they could infer what the limit is for the platform), but I'm not sure how useful it would be to the application developer. I don't mind one way or the other.

If we do decide to have a platform-independent nesting level, we would specify that limit. I'm still not sure whether we want to do this, but as I mentioned in another comment, there are some advantages to it.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2010884214

From zelmidaoui at openjdk.org  Mon Mar 24 20:51:17 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Mon, 24 Mar 2025 20:51:17 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
Message-ID: <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>

On Mon, 17 Mar 2025 15:21:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed two issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   arabic

The tests run successfully with the fix however there are a few things that do not work as expected I guess :
1- Pasting text from notes app (MacOS) that uses numbered list in some cases shows 0. instead of the item number example: 
- in note app do something like this 

Test
1. one
2. two
3. three
Test

- Copy and paste it is rendred like this 

Test
0. one
0. two
0. three
Test

2- Tested with text written in outlook and pasting it and it do not apply formatting neither for RTL or LTR text
3- another thing the arabic diacritics text is not rendered correctly (this may not be related to this issue specifically) you can try with this text  ?????????? ??????????

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2749356520

From mfox at openjdk.org  Mon Mar 24 21:03:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 24 Mar 2025 21:03:23 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <259SCh8aKMCAwTMMSV4H-MVWqmQJ6dnhZxJ8H_goznw=.9d322dd2-1ab4-4fd9-82d4-08f3c6eb7868@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>
 <nMZ6MpYouzXejh3GIlv1vNXQ8yW3qKSsHCL3g8cLux4=.6460a487-8fc5-4a59-80df-ca318a839db6@github.com>
 <259SCh8aKMCAwTMMSV4H-MVWqmQJ6dnhZxJ8H_goznw=.9d322dd2-1ab4-4fd9-82d4-08f3c6eb7868@github.com>
Message-ID: <j2OGJsRoaRSjEo358my9amGjHqfYzfA2w1sJP54kQl4=.3dc8a16d-8dc0-4dcb-bff3-dc5d7b94e388@github.com>

On Mon, 24 Mar 2025 19:56:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > We might want to consider imposing a limit on Linux and Windows, too. It could probably be done as a follow-up...
> 
> Although doing it as part of this PR would be OK, too. Which would you prefer?

And there it is, that open can of worms.

I will put together a cross-platform version of this PR and do some testing. My first impulse was to do a focused PR that addressed the Mac-only issue reported by the customer. But if my testing is correct (I'll double-check) it looks like that same customer was within throwing distance of destabilizing the system on Windows also. And there is a testing advantage to having it be consistent across platforms.

This PR makes a distinction between nested event loops started in Platform.runLater runnables and ones started while handling an input event (the former counts against the limit and the latter doesn't). A centralized solution will probably lose that distinction but I'm not sure that's important. Exceeding 240+ nested events loops is problematic either way.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2749384904

From angorya at openjdk.org  Mon Mar 24 21:11:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 21:11:18 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
 <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
Message-ID: <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>

On Mon, 24 Mar 2025 20:47:17 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   arabic
>
> The tests run successfully with the fix however there are a few things that do not work as expected I guess :
> 1- Pasting text from notes app (MacOS) that uses numbered list in some cases shows 0. instead of the item number example: 
> - in note app do something like this 
> 
> Test
> 1. one
> 2. two
> 3. three
> Test
> 
> - Copy and paste it is rendred like this 
> 
> Test
> 0. one
> 0. two
> 0. three
> Test
> 
> 2- Tested with text written in outlook and pasting it and it do not apply formatting neither for RTL or LTR text
> 3- another thing the arabic diacritics text is not rendered correctly (this may not be related to this issue specifically) you can try with this text  ?????????? ??????????

@Ziad-Mid : 
interesting, thank you!

1. The list formatting was not explicitly supported, so in a sense it works as designed (all numbered items are represented by `{\listtext	0.	}`.  This will likely be a separate enhancement.

2. RTL/LTR attributes are not yet supported by the demo due to many bugs in RTL.

3. Arabic diacritics rendered with the System font look bad, I agree.  Maybe @prrace can weigh on it, looks like changing the font to one of the Arabic ones does improve the rendering, although the result appears not as good compared to Chrome:

![Screenshot 2025-03-24 at 13 58 56](https://github.com/user-attachments/assets/6f999f8c-2bd0-4cff-85f1-40428ca867db)

![Screenshot 2025-03-24 at 13 59 33](https://github.com/user-attachments/assets/d6827435-4b64-455e-ac95-02f70d5c656d)

![Screenshot 2025-03-24 at 14 02 47](https://github.com/user-attachments/assets/005a6bee-4d98-4251-b5e1-2af043c4e837)

Can you try setting different fonts?

 ?????????? ?????????? =

\u0627\u0644\u0633\u0651\u064e\u0644\u064e\u0627\u0645\u064f \u0639\u064e\u0644\u064e\u064a\u0652\u0643\u064f\u0645\u0652

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2749400073

From angorya at openjdk.org  Mon Mar 24 21:22:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 21:22:19 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
Message-ID: <2npnfDQnQzwGSb1Lnu69Mgn3Vg1c3UGUmOCvGcMdIAM=.db7e0fc1-aa37-4192-a124-935f583c1478@github.com>

On Mon, 17 Mar 2025 15:21:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed two issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   arabic

Weird, even "Noto Sans Arabic" font produces weirdly positioned diacritics in JavaFX, while it's ok in MS Word:

![Screenshot 2025-03-24 at 14 19 22](https://github.com/user-attachments/assets/06b97e09-05e5-4a6e-b598-f6c39ef162f4)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2749424474

From jhendrikx at openjdk.org  Mon Mar 24 21:24:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 24 Mar 2025 21:24:15 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <JtZeFwHUFCTcJNU0PLekHO9FCAPbFKxf7PPTflY8lF4=.72bca3ca-4a0c-4fa6-92a6-f074747de7cd@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
 <wUV1kso66uEzarkxK2ksRTq983TvKCYuYvd-xVWmh1A=.6c6d3698-c9e3-451c-9ccb-f05e56721a34@github.com>
 <XvBbgp_KcLnHikIdb4zR4iM4qmvUUcH8myPI50BcazU=.4021a2b9-4f4e-4b3e-8c98-43d13179e0c4@github.com>
 <HL3CMERGmNGZ8gkkuqNpL-t_RdskhVNqkKuVOanUsXc=.a3b21898-d356-4e48-bec3-a853abb24a25@github.com>
 <_7ebbpClERrChH0Yew5O_H08hg7G_M4TFzNpT1Unb0s=.d6979505-04a2-4529-be6b-f5090ca7d13d@github.com>
 <gmfRPkkXNNcqun5AiLgl4bq1ib8phUnh4haqrNnmOSw=.4e999851-e7e8-4075-9398-ffec7028c2e5@github.com>
 <tf4l_YxIicp8HX2VJJbkuWbfFxwdIWKd8RI0ZSVW2kc=.7bd50913-8d90-4fbf-927c-04b1e9790f49@github.com>
 <tPwoPglueG7jL8BJFOhqHquZS52RxnQS4jjjhLlSG6c=.23ca6a11-c60b-4140-bd9c-ff7bad0d818d@github.com>
 <JtZeFwHUFCTcJNU0PLekHO9FCAPbFKxf7PPTflY8lF4=.72bca3ca-4a0c-4fa6-92a6-f074747de7cd@github.com>
Message-ID: <vGU5cnvO0njx-ywSkFcBrRRK946gMjL28_say4GLiks=.72589e5d-77cd-4c8a-84a3-cb036dec4fe4@github.com>

On Mon, 24 Mar 2025 17:55:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think you are onto something here.  It almost feels like we shouldn't be doing ceil/floor at all, rounding to the closest pixel instead.
>
> This would be a much larger change, though. Perhaps something to consider for a future discussion.

@kevinrushforth Yes, I wasn't intending to do anything about this in this change as it is unrelated.  I understand why `ceil` is used; FX distinguishes between sizes and spaces, where sizes are part of some visual part of a control, and spaces are non-control areas.  Spaces are generally ceil'd, so that even the thinnest control or border would show up as 1 pixel, while positions and spaces are just rounded.  Still, a border that would end up being 0.0001 pixels wide probably is still best hidden completely.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010943657

From jhendrikx at openjdk.org  Mon Mar 24 21:30:16 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 24 Mar 2025 21:30:16 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <FGX24srTC9BOzmAYy2E-oI1j9nOlhENicbUE9eprdx4=.d970206e-a3ed-4ba1-abd6-ae26efef4ce9@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
 <FGX24srTC9BOzmAYy2E-oI1j9nOlhENicbUE9eprdx4=.d970206e-a3ed-4ba1-abd6-ae26efef4ce9@github.com>
Message-ID: <AN0_hMC70qZfd_H3KeitxT605MrsoVd3mRK2RA4psk0=.f63f3976-5db7-4bdf-8d0b-3f3f73989072@github.com>

On Mon, 24 Mar 2025 17:59:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2093:
>> 
>>> 2091:         double right = margin != null ? snapSpaceX(margin.getRight(), snap) : 0;
>>> 2092: 
>>> 2093:         return width - left - right;
>> 
>> snap?
>
> @hjohn You may have answered this question in the larger discussion above, but I wanted to double-check.

Yes, sorry, this was addressed in the larger discussion.  I've left this as-is to keep the PR focus'd on one thing.

The calculation here is using 3 snapped values, and one can reasonably assume the result is "nearly" snapped.  If this value is used later with a ceiling function though, then it might ceil to the next higher value if the result is slightly too high due to floating point errors.  This is why it might be a good idea to adjust how our ceiling functions work in all cases; instead of using a tiny epsilon (or ulp), use a much larger value but still tiny in terms of pixels (like 1/10000th of a pixel).  Any "near" snapped values won't accidentally get rounded up to the next higher pixel then when ceil is used.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010949531

From jhendrikx at openjdk.org  Mon Mar 24 21:30:15 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Mon, 24 Mar 2025 21:30:15 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
Message-ID: <ZnZTF7tPSPHlI_sjMHF-kZ0nlxGyNXsL80PZmYLp2YY=.275eb46c-835c-4eb1-abc5-4164eaae6953@github.com>

On Mon, 24 Feb 2025 17:30:29 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify terms
>
> modules/javafx.graphics/src/main/java/javafx/scene/layout/Region.java line 2049:
> 
>> 2047:      *
>> 2048:      * The space allocated to a child, minus its margins, adjusted according to
>> 2049:      * its constraints (min <= X <= max). These are never -1.
> 
> always `> 0.0` here?

0 is probably still allowed, but it shouldn't be negative.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010950214

From angorya at openjdk.org  Mon Mar 24 21:33:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 24 Mar 2025 21:33:16 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <AN0_hMC70qZfd_H3KeitxT605MrsoVd3mRK2RA4psk0=.f63f3976-5db7-4bdf-8d0b-3f3f73989072@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
 <FGX24srTC9BOzmAYy2E-oI1j9nOlhENicbUE9eprdx4=.d970206e-a3ed-4ba1-abd6-ae26efef4ce9@github.com>
 <AN0_hMC70qZfd_H3KeitxT605MrsoVd3mRK2RA4psk0=.f63f3976-5db7-4bdf-8d0b-3f3f73989072@github.com>
Message-ID: <p8kLW8vC1iyg4JZGR_uLw8TNK2pu-llcpnKN9Q9iG10=.5d99996a-d4ef-4541-b85d-0a226222a0aa@github.com>

On Mon, 24 Mar 2025 21:26:53 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Any "near" snapped values won't accidentally get rounded up to the next higher pixel

I like this idea!

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2010953537

From kcr at openjdk.org  Mon Mar 24 23:13:13 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 24 Mar 2025 23:13:13 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <p8kLW8vC1iyg4JZGR_uLw8TNK2pu-llcpnKN9Q9iG10=.5d99996a-d4ef-4541-b85d-0a226222a0aa@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <R01V6jvvGqfLjmtfSD5w7FERfrUkAYDLNFgNdZhVLHs=.bfa92b0e-895c-4f25-af28-954b51dd87c0@github.com>
 <FGX24srTC9BOzmAYy2E-oI1j9nOlhENicbUE9eprdx4=.d970206e-a3ed-4ba1-abd6-ae26efef4ce9@github.com>
 <AN0_hMC70qZfd_H3KeitxT605MrsoVd3mRK2RA4psk0=.f63f3976-5db7-4bdf-8d0b-3f3f73989072@github.com>
 <p8kLW8vC1iyg4JZGR_uLw8TNK2pu-llcpnKN9Q9iG10=.5d99996a-d4ef-4541-b85d-0a226222a0aa@github.com>
Message-ID: <rdIKDRxe7OGpXxQcrzwzRgtHT0YszM8IUfCGMaTEsqo=.0e1f51d8-1b18-407f-be9f-79eb5f2143d1@github.com>

On Mon, 24 Mar 2025 21:30:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yes, sorry, this was addressed in the larger discussion.  I've left this as-is to keep the PR focus'd on one thing.
>> 
>> The calculation here is using 3 snapped values, and one can reasonably assume the result is "nearly" snapped.  If this value is used later with a ceiling function though, then it might ceil to the next higher value if the result is slightly too high due to floating point errors.  This is why it might be a good idea to adjust how our ceiling functions work in all cases; instead of using a tiny epsilon (or ulp), use a much larger value but still tiny in terms of pixels (like 1/10000th of a pixel).  Any "near" snapped values won't accidentally get rounded up to the next higher pixel then when ceil is used.
>
>> Any "near" snapped values won't accidentally get rounded up to the next higher pixel
> 
> I like this idea!

I agree. This sounds promising.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1723#discussion_r2011043278

From oschmidtmer at openjdk.org  Tue Mar 25 09:39:23 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Tue, 25 Mar 2025 09:39:23 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4]
In-Reply-To: <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <zfUIlWadRmSXrqKGMS5l50jk6VrnUEX0z-M0BGvHitw=.00d0a79f-6573-434d-831f-9f21f920e432@github.com>
 <QGwYk-SfbbYOJouHxTePyVnmwvZX6x9knmSIzbJq-v8=.234a94c3-8916-425c-a52d-77ef5542c0b7@github.com>
 <wQ6ydnTeXl4qbuoVxZPlDdSV5US-WpkKrcbSjL6w3zE=.5ce2312d-78df-4b75-bd44-1d79a87cfb6a@github.com>
 <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
Message-ID: <GicLrAZyi8S-NKF5Sh7f1AiRAOPkn3D1b-fT8Lo3d-E=.e292dea0-0abd-4cef-a9a0-b79db43a84e2@github.com>

On Fri, 28 Feb 2025 16:48:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> As the existing code was already pretty optimistic about 2 byte chars, is it possible that is already handled somewhere else?
>> I'm not sure whether this is done explicitly somewhere or if CF_UNICODETEXT is just tried first.
>
> Could be, but in any case, the way it's impemented right now doesn't seem to be right. We should only assume 2-byte characters if what's being pulled from the clipboard is actually `CF_UNICODETEXT`.

As @mstr2 said, I think the data is always converted to CF_UNICODETEXT. If it wasn't there should have been more visible problems, as the current code always assumes wide chars.

So I just need to know how much we should change within this ticket: Just removing CF_TEXT from here, or also removing flavors from create_mime_stuff().

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2011696298

From lkostyra at openjdk.org  Tue Mar 25 09:55:24 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Tue, 25 Mar 2025 09:55:24 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4]
In-Reply-To: <GicLrAZyi8S-NKF5Sh7f1AiRAOPkn3D1b-fT8Lo3d-E=.e292dea0-0abd-4cef-a9a0-b79db43a84e2@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <zfUIlWadRmSXrqKGMS5l50jk6VrnUEX0z-M0BGvHitw=.00d0a79f-6573-434d-831f-9f21f920e432@github.com>
 <QGwYk-SfbbYOJouHxTePyVnmwvZX6x9knmSIzbJq-v8=.234a94c3-8916-425c-a52d-77ef5542c0b7@github.com>
 <wQ6ydnTeXl4qbuoVxZPlDdSV5US-WpkKrcbSjL6w3zE=.5ce2312d-78df-4b75-bd44-1d79a87cfb6a@github.com>
 <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
 <GicLrAZyi8S-NKF5Sh7f1AiRAOPkn3D1b-fT8Lo3d-E=.e292dea0-0abd-4cef-a9a0-b79db43a84e2@github.com>
Message-ID: <nX5Ax6vvJ1Qfhwc7IEfsCEOrRrl5L7tFi4SnP6e8kWg=.9922ab04-45fe-4a0e-a53e-4fffe87f637c@github.com>

On Tue, 25 Mar 2025 09:36:46 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Could be, but in any case, the way it's impemented right now doesn't seem to be right. We should only assume 2-byte characters if what's being pulled from the clipboard is actually `CF_UNICODETEXT`.
>
> As @mstr2 said, I think the data is always converted to CF_UNICODETEXT. If it wasn't there should have been more visible problems, as the current code always assumes wide chars.
> 
> So I just need to know how much we should change within this ticket: Just removing CF_TEXT from here, or also removing flavors from create_mime_stuff().

I think the point is to explicitly request `CF_UNICODETEXT` and, if Clipboard has `CF_TEXT` or `CF_OEMTEXT` inside, it will automatically convert it to Unicode on output. This way we ensure we always get 2-byte Unicode text independently of Clipboard contents. So I would say to change the flavors in `create_mime_stuff()` as well.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2011726310

From zelmidaoui at openjdk.org  Tue Mar 25 12:41:21 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 12:41:21 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
 <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
 <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>
Message-ID: <oRAGtUmsleTm934fst11fuOjTCze5BUbdX97yRdS5o8=.ee928315-562e-4ddf-bb42-79816f26a16f@github.com>

On Mon, 24 Mar 2025 21:06:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> 2. RTL/LTR attributes are not yet supported by the demo due to many bugs in RTL.
By RTL and LTR I just meant normal text orientation and arabic one , when writing a text in outlook and copying it then pasting it doesn't keep the formatting

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2751124680

From kcr at openjdk.org  Tue Mar 25 14:28:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 14:28:18 GMT
Subject: RFR: 8350149: VBox ignores bias of child controls when fillWidth
 is set to false [v4]
In-Reply-To: <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
 <VcQA0LdIbEGaRNY6CWzKa3jF4e-KxrppBWKzbHDU4_4=.e4aff6cd-fe3f-4d5a-a772-11657d5d12f0@github.com>
Message-ID: <tqLu1_HU1yVSoQ1GNrx2vPEZexj8Sq1rwP1FOTXM42U=.aa03ae5d-c090-4a6b-a63b-58f92d3aefbb@github.com>

On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
>> 
>> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
>> 
>> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
>> 
>> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
>> 
>> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
>> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
>> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
>> 
>> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
>> 
>> **Note**: some tests have had their va...
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify terms

I think all questions have been resolved; if so, this is ready to integrate.

Let's file a follow-on bug to address possible changes to snapping.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1723#issuecomment-2751447636

From angorya at openjdk.org  Tue Mar 25 14:40:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 14:40:18 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <oRAGtUmsleTm934fst11fuOjTCze5BUbdX97yRdS5o8=.ee928315-562e-4ddf-bb42-79816f26a16f@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
 <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
 <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>
 <oRAGtUmsleTm934fst11fuOjTCze5BUbdX97yRdS5o8=.ee928315-562e-4ddf-bb42-79816f26a16f@github.com>
Message-ID: <XZ9nm2syOCghJJXaFXcm2JTgRXY51O5AO922XM3BHyA=.0c497bc5-6dcc-4aeb-bb97-245047e9acbf@github.com>

On Tue, 25 Mar 2025 12:38:51 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> doesn't keep the formatting

please be more specific - maybe include a screenshot of the outlook message vs. rich text area?

I can see the pasted Arabic text rendered correctly (that is, it looks similar to the text in outlook and going from right to left).  The RTL _paragraph attribute_ is not yet supported, so the paragraph consisting of only Arabic text might look left-aligned contrary to expectation.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2751484473

From zelmidaoui at openjdk.org  Tue Mar 25 14:56:18 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 14:56:18 GMT
Subject: RFR: 8351878: RichTextArea: Pasting from RTF doesn't apply
 formatting [v3]
In-Reply-To: <XZ9nm2syOCghJJXaFXcm2JTgRXY51O5AO922XM3BHyA=.0c497bc5-6dcc-4aeb-bb97-245047e9acbf@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
 <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
 <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>
 <oRAGtUmsleTm934fst11fuOjTCze5BUbdX97yRdS5o8=.ee928315-562e-4ddf-bb42-79816f26a16f@github.com>
 <XZ9nm2syOCghJJXaFXcm2JTgRXY51O5AO922XM3BHyA=.0c497bc5-6dcc-4aeb-bb97-245047e9acbf@github.com>
Message-ID: <7KnTUmweRxFxnS7khi8yrXC3rd2A0G1fYyfcEm9FcgI=.cf44cfa3-ca45-4817-82b5-418d6411c5f9@github.com>

On Tue, 25 Mar 2025 14:37:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> please be more specific - maybe include a screenshot of the outlook message vs. rich text area?

The font and size are not applied 
![Screenshot 2025-03-25 at 14 50 25](https://github.com/user-attachments/assets/5fdaf578-cc2c-41e6-9e09-7128538b2c4d)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2751539606

From jhendrikx at openjdk.org  Tue Mar 25 14:59:29 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Tue, 25 Mar 2025 14:59:29 GMT
Subject: Integrated: 8350149: VBox ignores bias of child controls when
 fillWidth is set to false
In-Reply-To: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
References: <ZVARhQ7cpZdv5E3K-2asYaZwkNjsW4ifCU5BW7cbF78=.06f4c131-549a-4bbd-bd30-8d8eae52c2bf@github.com>
Message-ID: <s0cn136Y95IvZqfKYK5yAv-0i70zt3dmOM-w5tqNJV8=.0575f9b0-3816-4325-a386-cc7383dcc8ad@github.com>

On Sat, 22 Feb 2025 15:57:28 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> Fixes the case where `VBox` will ignore the (horizontal) bias of a child when its fill width property is set to `false`.  This manifests itself with labels that have their wrap text property set to `true`, and the container is not wide enough to hold the text on a single line (in other words, the label is potentially far wider, and fill width should have no effect).  No reflow would occur before this fix.
> 
> The solution is to ensure the `computeChildAreaMin/Pref/MaxHeight` functions are provided with a `fillWidth` parameter, to be used in the case a horizontally biased control is encountered (several of the parameters to these compute functions are only used for those special cases and ignored otherwise).
> 
> With this additional information, the compute functions can decide between the preferred width of a control or the available width of the container.  In the old implementation this decision was made *before* these functions were called, and the available width was reset to -1 to indicate the case that the preferred width should be used.  However, there are three cases, and so setting a single parameter to -1 can't effectively communicate that:
> 
> Assuming a control that is horizontally biased, and is resizable there are three cases when calculating a **height**:
> 
> 1. There is no available width: bias is ignored (as there is no value to use as a dependent value) and the height is then simply calculated ignoring available width (which is -1) and fill width settings (same as unbiased controls).
> 2. There is an available width and fill width is false; the bias logic must first find a reasonable width before it can call any height function; with fill width false, this reasonable width will be the preferred width of the control, unless it exceeds its maximum width or the available width, in which case the smallest of these three values is used.  The final width calculated is then used to determine the height.
> 3. There is an available width and fill width is true; this is the same as case 2, except the available width is used as a dependent value (unless its greater than the child's maximum width, in which case the smaller is used).  The final width calculated is then used to determine the height.
> 
> All in all, this PR removes several inconsistencies between horizontal and vertical computations. The end result is that the horizontal and vertical bias calculations now more closely mirror each other.
> 
> **Note**: some tests have had their values adjusted.  This is becaus...

This pull request has now been integrated.

Changeset: a550e5e4
Author:    John Hendrikx <jhendrikx at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/a550e5e4965fa0f9f4732364e4b20e8fa8cbcbd1
Stats:     998 lines in 12 files changed: 818 ins; 49 del; 131 mod

8350149: VBox ignores bias of child controls when fillWidth is set to false

Reviewed-by: angorya, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1723

From kcr at openjdk.org  Tue Mar 25 17:28:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 17:28:21 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <04VAS5ExdzCwS8Z1W0szpWw-kji3tBkHOqa8gFTT6O0=.93311bd5-ebc6-415f-bbdf-2f8e5bd80115@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

I think we will eventually settle on one of two solutions. In both cases we will want to document the concept of a limited nesting depth and encourage application developers to check `Platform.canStartNestedEventLoop` if they want to be sure that the platform can start one.

The two options are:

1. Make the limit platform-specific limit. The API docs will therefore not mention any particular limit. Each glass platform would implement `Application.canStartNestedEventLoop` imposing the limit for that platform. We _might_ consider documenting a guaranteed lower limit that is well below any specific platform limit (e.g., 150).
2. Make the limit platform-independent. We could, and probably should, choose to document this limit. We could choose to implement Application.canStartNestedEventLoop in shared code rather than overriding it in the pipeline. We would need to pick a safe "lowest common denominator" (maybe 200).

My gut feel is that we should go with option 1 and keep this platform-specific, which means we would not specify the limit (other than maybe giving a guarantee of "at least 150"), unless there are good arguments in favor of option 2 that we haven't considered.

Comments?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752001549

From angorya at openjdk.org  Tue Mar 25 17:28:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 17:28:22 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <XSOBSRXBx7w1qIGFEAPkbzZj2tjRSfkXdW3K7LQCKcs=.2f533a1e-c222-4a31-9fe9-775f133182b6@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

I am leaning toward option 2, because I think having too many nested loop in an application is a design problem.  In a well-behaved application the number should never exceed some relatively small number so having a universal and relatively high number (~200) would be a good safeguard.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752014609

From kcr at openjdk.org  Tue Mar 25 17:28:22 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 17:28:22 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <j2OGJsRoaRSjEo358my9amGjHqfYzfA2w1sJP54kQl4=.3dc8a16d-8dc0-4dcb-bff3-dc5d7b94e388@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <v7iboBxom0zHiq2sCVvnaTHphW9teFFdi9mbyX7IDTE=.6158ea62-5255-44f5-8ba2-bd661e5fdb2f@github.com>
 <nMZ6MpYouzXejh3GIlv1vNXQ8yW3qKSsHCL3g8cLux4=.6460a487-8fc5-4a59-80df-ca318a839db6@github.com>
 <259SCh8aKMCAwTMMSV4H-MVWqmQJ6dnhZxJ8H_goznw=.9d322dd2-1ab4-4fd9-82d4-08f3c6eb7868@github.com>
 <j2OGJsRoaRSjEo358my9amGjHqfYzfA2w1sJP54kQl4=.3dc8a16d-8dc0-4dcb-bff3-dc5d7b94e388@github.com>
Message-ID: <tij0QG4mjbKwqr5ZNv7MRYsL78D0Xi7ix1s0X26IDWo=.0b8eb230-f82e-494c-8084-e14a8047f64a@github.com>

On Mon, 24 Mar 2025 21:00:38 GMT, Martin Fox <mfox at openjdk.org> wrote:

> A centralized solution will probably lose that distinction but I'm not sure that's important. Exceeding 240+ nested events loops is problematic either way.

Agreed.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752007782

From kcr at openjdk.org  Tue Mar 25 17:31:18 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 17:31:18 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v4]
In-Reply-To: <nX5Ax6vvJ1Qfhwc7IEfsCEOrRrl5L7tFi4SnP6e8kWg=.9922ab04-45fe-4a0e-a53e-4fffe87f637c@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <zfUIlWadRmSXrqKGMS5l50jk6VrnUEX0z-M0BGvHitw=.00d0a79f-6573-434d-831f-9f21f920e432@github.com>
 <QGwYk-SfbbYOJouHxTePyVnmwvZX6x9knmSIzbJq-v8=.234a94c3-8916-425c-a52d-77ef5542c0b7@github.com>
 <wQ6ydnTeXl4qbuoVxZPlDdSV5US-WpkKrcbSjL6w3zE=.5ce2312d-78df-4b75-bd44-1d79a87cfb6a@github.com>
 <5WNxpqtKktu-UMarvNgQ8Ya-65uGwonb-HiseARYipc=.97b8db04-e777-4f4b-b66f-67135b07f485@github.com>
 <GicLrAZyi8S-NKF5Sh7f1AiRAOPkn3D1b-fT8Lo3d-E=.e292dea0-0abd-4cef-a9a0-b79db43a84e2@github.com>
 <nX5Ax6vvJ1Qfhwc7IEfsCEOrRrl5L7tFi4SnP6e8kWg=.9922ab04-45fe-4a0e-a53e-4fffe87f637c@github.com>
Message-ID: <pxw1bRacy5-OJ8a0VZ2tuoKUmNh36zEuZAQdE-8g7ZQ=.0323540d-6670-40bb-9753-d56be0b70e6f@github.com>

On Tue, 25 Mar 2025 09:53:10 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> As @mstr2 said, I think the data is always converted to CF_UNICODETEXT. If it wasn't there should have been more visible problems, as the current code always assumes wide chars.
>> 
>> So I just need to know how much we should change within this ticket: Just removing CF_TEXT from here, or also removing flavors from create_mime_stuff().
>
> I think the point is to explicitly request `CF_UNICODETEXT` and, if Clipboard has `CF_TEXT` or `CF_OEMTEXT` inside, it will automatically convert it to Unicode on output. This way we ensure we always get 2-byte Unicode text independently of Clipboard contents. So I would say to change the flavors in `create_mime_stuff()` as well.

That makes sense to me, too. I was originally thinking that removing the `CF_TEXT == cf ||` in this `if` statement would be sufficient, but it's certainly safer, and seems more correct, to also ensure that we request `CF_UNICODETEXT`, given that here and in the calling Java code, we assume 2-byte Unicode.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2012594032

From angorya at openjdk.org  Tue Mar 25 17:37:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 17:37:34 GMT
Subject: RFR: 8313424: JavaFX controls in the title bar [v59]
In-Reply-To: <rODUnW5oS3iOFFi4WH8UjLZ0jQkfORDjZVR35_v-H9A=.45491376-9d5e-4d33-8ba6-a358dc7b7f03@github.com>
References: <GAFsiEYWj5pi-uVMXBG1-wPTosWs8QMWYOYZ0OOFksQ=.38250091-a34a-44ca-a07c-e68afa043903@github.com>
 <rODUnW5oS3iOFFi4WH8UjLZ0jQkfORDjZVR35_v-H9A=.45491376-9d5e-4d33-8ba6-a358dc7b7f03@github.com>
Message-ID: <mRDU46fpuoUJZZyVTLqp_GUj89vFDk4VEKaqVEqdH6A=.71f33fbf-754c-466a-8ac4-dd71a3f70ed3@github.com>

On Sun, 23 Mar 2025 09:21:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Implementation of [`EXTENDED`](https://gist.github.com/mstr2/0befc541ee7297b6db2865cc5e4dbd09) and `EXTENDED_UTILITY` stage style.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   documentation

Thank you for making the changes!
Looks good on windows in all resolutions available for my external monitor, from 100% to 225%.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1605#pullrequestreview-2714620777

From angorya at openjdk.org  Tue Mar 25 18:19:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 18:19:26 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
Message-ID: <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>

On Sat, 22 Mar 2025 12:20:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
> 
> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
> 
> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

Looks good!

Also tried with `titleRegion.getAlignment()` code removed - still works as expected.  I agree with John it looks wrong.

The problem with inability to truncate the title label by setting max/pref width might be a separate issue since it's also present in the `master` branch.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 160:

> 158:         registerChangeListener(titleRegion.alignmentProperty(), e -> pos = titleRegion.getAlignment());
> 159: 
> 160:         // NOTE: Listening to two different alignment properties, and using the last value of either is likely a bug!

I agree: it is definitely a bug.  I think we should remove it along with the possibility of specifying conflicting alignment via CSS.  The control must be in control.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 514:

> 512:              */
> 513: 
> 514:             double labelPrefWidth = TitledPaneSkin.super.computePrefWidth(height, 0, 0, 0, 0);

On a related subject: trying to get the title label truncated (using the code sample in the ticket) did not succeed even though the TitledPane is a Labeled:


        TitledPane tp1 = new TitledPane("Left Aligned Title with a long long title with ellipses set", ...);
        tp1.setPrefWidth(100);
        tp1.setMaxWidth(100);
        tp1.setEllipsisString("...");


This seems like a possible bug to me.  What do you think?

-------------

PR Review: https://git.openjdk.org/jfx/pull/1742#pullrequestreview-2714550584
PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2012561300
PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2012653146

From oschmidtmer at openjdk.org  Tue Mar 25 18:39:08 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Tue, 25 Mar 2025 18:39:08 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v6]
In-Reply-To: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
Message-ID: <EwgssHEl4tDuqmnTLquybqO3iDfLh3EeVWChyv1mbiA=.6f1dc7cf-eea2-4711-93f5-638b2d98c710@github.com>

> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
> 
> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  remove non unicode textformats

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1724/files
  - new: https://git.openjdk.org/jfx/pull/1724/files/6ef3353e..c91ab3b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=04-05

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1724.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724

PR: https://git.openjdk.org/jfx/pull/1724

From crschnick at xpipe.io  Tue Mar 25 18:52:33 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Tue, 25 Mar 2025 19:52:33 +0100
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
Message-ID: <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>

Hey Andy,

so I think I was able to reproduce this issue for our application.

There are two main factors how this can happen:
- We use an alert-based error reporter, meaning that we have a default 
uncaught exception handler set for all threads which will showAndWait an 
Alert with the exception message
- As I reported yesterday with 
https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, 
there are some rare exceptions that can occur in a normal event loop 
without interference of the application, probably because of a small bug 
in the bounds calculation code

If you combine these two factors, you will end up with an infinite loop 
of the showAndWait entering a nested event loop, the event loop throwing 
an internal exception, and the uncaught exception handler starting the 
same loop with another alert. I don't think this is a bad implementation 
from our side, the only thing that we can improve is to maybe check how 
deep the uncaught exception loop is in to prevent this from occurring 
indefinitely. But I would argue this can happen to any application. Here 
is a sample code, based on the reproducer from the OutOfBounds report 
from yesterday:

import javafx.application.Application;
import javafx.application.Platform;
import javafx.scene.Scene;
import javafx.scene.control.Alert;
import javafx.scene.control.Button;
import javafx.scene.layout.Region;
import javafx.scene.layout.StackPane;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

import java.io.IOException;
import java.util.Arrays;

public class ParentBoundsBugextends Application {

     @Override public void start(Stage stage)throws IOException {
         Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
             throwable.printStackTrace();

             if (Platform.isFxApplicationThread()) {
                 var alert =new Alert(Alert.AlertType.ERROR);
                 alert.setHeaderText(throwable.getMessage());
                 alert.setContentText(Arrays.toString(throwable.getStackTrace()));
                 alert.showAndWait();
             }else {
                 // Do some other error handling for non-platform threads // Probably 
just show the alert with a runLater() // For this example, there are no 
exceptions outside the platform thread }
         });

         // Run delayed as Application::reportException will only be called for 
exceptions // after the application has started Platform.runLater(() -> {
             Scene scene =new Scene(createContent(),640,480);
             stage.setScene(scene);
             stage.show();
             stage.centerOnScreen();
         });
     }

     private RegioncreateContent() {
         var b1 =new Button("Click me!");
         var b2 =new Button("Click me!");
         var vbox =new VBox(b1, b2);
         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });

         var stack =new StackPane(vbox,new StackPane());
         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
             vbox.setVisible(!vbox.isVisible());
         });
         return stack;
     }

     public static void main(String[] args) {
         launch();
     }
}


If the same OutOfBounds exception from the reported I linked happens in 
the bounds calculation, which happens approximately 1/5 runs for me, 
this application will enter new event loops until it crashes. If the 
OutOfBounds doesn't trigger, it will just throw a StackOverflow but 
won't continue the infinite loop of nested event loops. So for the 
reproducer it is important to try a few times until you get the 
described OutOfBounds.

I attached the stacktrace of how this fails. The initial StackOverflow 
causes infinitely many following exceptions in the nested event loop.

Best
Christopher Schnick

On 25/03/2025 18:28, Andy Goryachev wrote:
>
> Dear Christopher:
>
> Were you able to root cause why your application enters that many 
> nested event loops?
>
> I believe a well-behaved application should never experience that, 
> unless there is some design flaw or a bug.
>
> -andy
>
> *From: *Christopher Schnick <crschnick at xpipe.io>
> *Date: *Monday, March 10, 2025 at 19:45
> *To: *Andy Goryachev <andy.goryachev at oracle.com>
> *Subject: *[External] : Re: JVM crashes on macOS when entering too 
> many nested event loops
>
> Our code and some libraries do enter some nested event loops at a few 
> places when it makes sense, but we didn't do anything to explicitly 
> provoke this, this occurred naturally in our application. So it would 
> be nice if JavaFX could somehow guard against this, especially since 
> crashing the JVM is probably the worst thing that can happen.
>
> I looked at the documentation, but it seems like the public API at 
> Platform::enterNestedEventLoop does not mention this.
> From my understanding, the method Platform::canStartNestedEventLoop is 
> potentially the right method to indicate to the caller that the limit 
> is close by returning false.
> And even if something like an exception is thrown when a nested event 
> loop is started while it is close to the limit, that would still be 
> much better than a direct crash.
>
> Best
> Christopher Schnick
>
> On 10/03/2025 18:51, Andy Goryachev wrote:
>
>     This looks to me like it might be hitting the (native) thread
>     stack size limit.
>
>     c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>
>     ???? * An application may enter several nested loops recursively.
>     There's no
>
>     ???? * limit of recursion other than that imposed by the native
>     stack size.
>
>     -andy
>
>     *From: *openjfx-dev <openjfx-dev-retn at openjdk.org>
>     <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox
>     <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>     *Date: *Monday, March 10, 2025 at 10:10
>     *To: *Christopher Schnick <crschnick at xpipe.io>
>     <mailto:crschnick at xpipe.io>
>     *Cc: *OpenJFX <openjfx-dev at openjdk.org>
>     <mailto:openjfx-dev at openjdk.org>
>     *Subject: *Re: JVM crashes on macOS when entering too many nested
>     event loops
>
>     Hi Christopher,
>
>     I was able to reproduce this crash. I wrote a small routine that
>     recursively calls itself in a runLater block and then enters a
>     nested event loop. The program crashes when creating loop 254. I?m
>     not sure where that limit comes from so it?s possible that
>     consuming some other system resource could lower it. I couldn?t
>     see any good way to determine how many loops are active by looking
>     at the crash report since it doesn?t show the entire call stack.
>     I did a quick trial on Linux and was able to create a lot more
>     loops (over 600) but then started seeing erratic behavior and
>     errors coming from the Java VM. The behavior was variable unlike
>     on the Mac which always crashes when creating loop 254.
>
>     Martin
>
>     > On Mar 7, 2025, at 6:24?AM, Christopher Schnick
>     <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>     >
>     > Hello,
>     >
>     > I have attached a JVM fatal error log that seemingly was caused
>     by our JavaFX application entering too many nested event loops,
>     which macOS apparently doesn't like.
>     >
>     > As far as I know, there is no upper limit defined on how often
>     an event loop can be nested, so I think this is a bug that can
>     occur in rare situations.
>     >
>     > Best
>     > Christopher Schnick<hs_err_pid.txt>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250325/9442ff5d/attachment-0001.htm>
-------------- next part --------------
java.lang.StackOverflowError
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3762)
	at javafx.graphics at 25-ea/javafx.scene.Parent.getChildTransformedBounds(Parent.java:1913)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1774)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties$2.computeBounds(Node.java:6866)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.get(Node.java:10191)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.get(Node.java:10182)
	at javafx.base at 25-ea/javafx.beans.binding.ObjectExpression.getValue(ObjectExpression.java:51)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:188)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childBoundsChanged(Parent.java:1938)
	at javafx.graphics at 25-ea/javafx.scene.Node.notifyParentOfBoundsChange(Node.java:4159)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4120)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1435)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
	at javafx.graphics at 25-ea/javafx.scene.Node.localBoundsChanged(Node.java:4102)
	at javafx.graphics at 25-ea/javafx.scene.Node.doGeomChanged(Node.java:4088)
	at javafx.graphics at 25-ea/javafx.scene.Node$1.doGeomChanged(Node.java:478)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChangedImpl(NodeHelper.java:170)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.geomChanged(NodeHelper.java:123)
	at javafx.graphics at 25-ea/javafx.scene.Parent.childVisibilityChanged(Parent.java:1951)
	at javafx.graphics at 25-ea/javafx.scene.Node$6.invalidated(Node.java:1441)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-ea/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-ea/javafx.css.StyleableBooleanProperty.set(StyleableBooleanProperty.java:103)
	at javafx.graphics at 25-ea/javafx.scene.Node.setVisible(Node.java:1420)
	at com.crschnick.javafxtest at 1.0-SNAPSHOT/com.crschnick.javafxtest.ParentBoundsBug.lambda$createContent$5(ParentBoundsBug.java:62)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper$SingleChange.fireValueChangedEvent(ExpressionHelper.java:192)
	at javafx.base at 25-ea/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(ExpressionHelper.java:91)
	at javafx.base at 25-ea/javafx.beans.property.ReadOnlyObjectPropertyBase.fireValueChangedEvent(ReadOnlyObjectPropertyBase.java:80)
	at javafx.graphics at 25-ea/javafx.scene.Node$LazyBoundsProperty.invalidate(Node.java:10201)
	at javafx.graphics at 25-ea/javafx.scene.Node$MiscProperties.invalidateBoundsInParent(Node.java:6894)
	at javafx.graphics at 25-ea/javafx.scene.Node.invalidateBoundsInParent(Node.java:3493)
	at javafx.graphics at 25-ea/javafx.scene.Node.transformedBoundsChanged(Node.java:4116)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)
java.lang.IndexOutOfBoundsException: Index -1 out of bounds for length 2
	at java.base/jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:100)
	at java.base/jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:106)
	at java.base/jdk.internal.util.Preconditions.checkIndex(Preconditions.java:302)
	at java.base/java.util.Objects.checkIndex(Objects.java:365)
	at java.base/java.util.ArrayList.get(ArrayList.java:428)
	at javafx.base at 25-ea/com.sun.javafx.collections.ObservableListWrapper.get(ObservableListWrapper.java:88)
	at javafx.base at 25-ea/com.sun.javafx.collections.VetoableListDecorator.get(VetoableListDecorator.java:326)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateCachedBounds(Parent.java:1769)
	at javafx.graphics at 25-ea/javafx.scene.Parent.recomputeBounds(Parent.java:1713)
	at javafx.graphics at 25-ea/javafx.scene.Parent.doComputeGeomBounds(Parent.java:1566)
	at javafx.graphics at 25-ea/javafx.scene.Parent$1.doComputeGeomBounds(Parent.java:116)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.ParentHelper.computeGeomBoundsImpl(ParentHelper.java:84)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBoundsImpl(RegionHelper.java:78)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.superComputeGeomBounds(RegionHelper.java:62)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region.doComputeGeomBounds(Region.java:3301)
	at javafx.graphics at 25-ea/javafx.scene.layout.Region$1.doComputeGeomBounds(Region.java:166)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.layout.RegionHelper.computeGeomBoundsImpl(RegionHelper.java:89)
	at javafx.graphics at 25-ea/com.sun.javafx.scene.NodeHelper.computeGeomBounds(NodeHelper.java:101)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateGeomBounds(Node.java:3908)
	at javafx.graphics at 25-ea/javafx.scene.Node.getGeomBounds(Node.java:3870)
	at javafx.graphics at 25-ea/javafx.scene.Node.getLocalBounds(Node.java:3818)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateTxBounds(Node.java:3972)
	at javafx.graphics at 25-ea/javafx.scene.Node.getTransformedBounds(Node.java:3764)
	at javafx.graphics at 25-ea/javafx.scene.Node.updateBounds(Node.java:828)
	at javafx.graphics at 25-ea/javafx.scene.Parent.updateBounds(Parent.java:1900)
	at javafx.graphics at 25-ea/javafx.scene.Scene$ScenePulseListener.pulse(Scene.java:2670)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.runPulse(Toolkit.java:380)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.Toolkit.firePulse(Toolkit.java:401)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:592)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulse(QuantumToolkit.java:572)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.pulseFromQueue(QuantumToolkit.java:565)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$6(QuantumToolkit.java:346)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run$$$capture(InvokeLaterDispatcher.java:95)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java)
	at --- Async.Stack.Trace --- (captured by IntelliJ IDEA debugger)
	at javafx.graphics at 25-ea/com.sun.glass.ui.InvokeLaterDispatcher.invokeLater(InvokeLaterDispatcher.java)
	at javafx.graphics at 25-ea/com.sun.glass.ui.win.WinApplication._invokeLater(WinApplication.java:321)
	at javafx.graphics at 25-ea/com.sun.glass.ui.Application.invokeLater(Application.java:480)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.postPulse(QuantumToolkit.java:512)
	at javafx.graphics at 25-ea/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$runToolkit$7(QuantumToolkit.java:349)



From andy.goryachev at oracle.com  Tue Mar 25 19:16:20 2025
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Tue, 25 Mar 2025 19:16:20 +0000
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
Message-ID: <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>

Thank you, Christopher, for clarification!

Personally, I would consider this to be a problem with the application design: the code should limit the number of alerts shown to the user.  Do you really want the user to click through hundreds of alerts?

Nevertheless, you are right about the need for the platform to gracefully handle the case of too many nested event loops - by throwing an exception with a meaningful message, as Martin proposed in https://github.com/openjdk/jfx/pull/1741

Cheers,
-andy



From: Christopher Schnick <crschnick at xpipe.io>
Date: Tuesday, March 25, 2025 at 11:52
To: Andy Goryachev <andy.goryachev at oracle.com>
Cc: OpenJFX <openjfx-dev at openjdk.org>
Subject: Re: [External] : Re: JVM crashes on macOS when entering too many nested event loops

Hey Andy,

so I think I was able to reproduce this issue for our application.

There are two main factors how this can happen:
- We use an alert-based error reporter, meaning that we have a default uncaught exception handler set for all threads which will showAndWait an Alert with the exception message
- As I reported yesterday with https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, there are some rare exceptions that can occur in a normal event loop without interference of the application, probably because of a small bug in the bounds calculation code

If you combine these two factors, you will end up with an infinite loop of the showAndWait entering a nested event loop, the event loop throwing an internal exception, and the uncaught exception handler starting the same loop with another alert. I don't think this is a bad implementation from our side, the only thing that we can improve is to maybe check how deep the uncaught exception loop is in to prevent this from occurring indefinitely. But I would argue this can happen to any application. Here is a sample code, based on the reproducer from the OutOfBounds report from yesterday:

import javafx.application.Application;

import javafx.application.Platform;

import javafx.scene.Scene;

import javafx.scene.control.Alert;

import javafx.scene.control.Button;

import javafx.scene.layout.Region;

import javafx.scene.layout.StackPane;

import javafx.scene.layout.VBox;

import javafx.stage.Stage;



import java.io.IOException;

import java.util.Arrays;



public class ParentBoundsBug extends Application {



    @Override

    public void start(Stage stage) throws IOException {

        Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {

            throwable.printStackTrace();



            if (Platform.isFxApplicationThread()) {

                var alert = new Alert(Alert.AlertType.ERROR);

                alert.setHeaderText(throwable.getMessage());

                alert.setContentText(Arrays.toString(throwable.getStackTrace()));

                alert.showAndWait();

            } else {

                // Do some other error handling for non-platform threads

                // Probably just show the alert with a runLater()



                // For this example, there are no exceptions outside the platform thread

            }

        });



        // Run delayed as Application::reportException will only be called for exceptions

        // after the application has started

        Platform.runLater(() -> {

            Scene scene = new Scene(createContent(), 640, 480);

            stage.setScene(scene);

            stage.show();

            stage.centerOnScreen();

        });

    }



    private Region createContent() {

        var b1 = new Button("Click me!");

        var b2 = new Button("Click me!");

        var vbox = new VBox(b1, b2);

        b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {

            vbox.setVisible(!vbox.isVisible());

        });

        b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {

            vbox.setVisible(!vbox.isVisible());

        });

        vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {

            vbox.setVisible(!vbox.isVisible());

        });



        var stack = new StackPane(vbox, new StackPane());

        stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {

            vbox.setVisible(!vbox.isVisible());

        });

        return stack;

    }



    public static void main(String[] args) {

        launch();

    }

}

If the same OutOfBounds exception from the reported I linked happens in the bounds calculation, which happens approximately 1/5 runs for me, this application will enter new event loops until it crashes. If the OutOfBounds doesn't trigger, it will just throw a StackOverflow but won't continue the infinite loop of nested event loops. So for the reproducer it is important to try a few times until you get the described OutOfBounds.

I attached the stacktrace of how this fails. The initial StackOverflow causes infinitely many following exceptions in the nested event loop.

Best
Christopher Schnick
On 25/03/2025 18:28, Andy Goryachev wrote:
Dear Christopher:

Were you able to root cause why your application enters that many nested event loops?

I believe a well-behaved application should never experience that, unless there is some design flaw or a bug.

-andy


From: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Date: Monday, March 10, 2025 at 19:45
To: Andy Goryachev <andy.goryachev at oracle.com><mailto:andy.goryachev at oracle.com>
Subject: [External] : Re: JVM crashes on macOS when entering too many nested event loops

Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.

I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.

Best
Christopher Schnick
On 10/03/2025 18:51, Andy Goryachev wrote:
This looks to me like it might be hitting the (native) thread stack size limit.

c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:


     * An application may enter several nested loops recursively. There's no

     * limit of recursion other than that imposed by the native stack size.


-andy



From: openjfx-dev <openjfx-dev-retn at openjdk.org><mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com><mailto:martinfox656 at gmail.com>
Date: Monday, March 10, 2025 at 10:10
To: Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io>
Cc: OpenJFX <openjfx-dev at openjdk.org><mailto:openjfx-dev at openjdk.org>
Subject: Re: JVM crashes on macOS when entering too many nested event loops
Hi Christopher,

I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.

Martin

> On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io><mailto:crschnick at xpipe.io> wrote:
>
> Hello,
>
> I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>
> As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>
> Best
> Christopher Schnick<hs_err_pid.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250325/e9191c5d/attachment-0001.htm>

From kcr at openjdk.org  Tue Mar 25 20:21:25 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 20:21:25 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
Message-ID: <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>

On Thu, 6 Mar 2025 16:21:52 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "fixed bad merge"
>   
>   This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.

Looks good. I left a few questions and a couple suggestions. I'll reapprove if you decide to change anything.

modules/javafx.controls/src/test/java/test/javafx/scene/chart/StackedBarChartTest.java line 116:

> 114:         String bounds = computeBoundsString((Region)childrenList.get(0), (Region)childrenList.get(1),
> 115:                 (Region)childrenList.get(2));
> 116:         assertEquals("10 440 216 34 236 397 216 77 461 345 216 129 ", bounds);

I presume these changes are needed because they are also hard-coded values that are changing with the StubToolkit changes?

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 100:

> 98: import test.com.sun.javafx.scene.control.test.RT_22463_Person;
> 99: 
> 100: /**

Minor: We don't typically use javadoc-style comments in the class docs of test classes, but since we have a global RFE to address this, I don't think it matters all that much.

modules/javafx.graphics/src/main/java/com/sun/javafx/text/GlyphLayoutManager.java line 42:

> 40:  */
> 41: public class GlyphLayoutManager {
> 42:     private static GlyphLayout REUSABLE_INSTANCE = newInstance();

This can be final.

modules/javafx.graphics/src/main/java/com/sun/javafx/text/GlyphLayoutManager.java line 43:

> 41: public class GlyphLayoutManager {
> 42:     private static GlyphLayout REUSABLE_INSTANCE = newInstance();
> 43:     private static final AtomicBoolean GUARD = new AtomicBoolean(false);

Minor: "IN_USE" seems like a better name (and is what the original code used).

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 57:

> 55:  * Prism TextLayout
> 56:  */
> 57: public abstract class PrismTextLayout implements TextLayout {

Minor: Instead of making this abstract, did you consider leaving it concrete, overriding the methods you need in StubTextLayout? It's fine to leave the change as you have it.

modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayoutFactory.java line 37:

> 35:     /* Same strategy as GlyphLayout */
> 36:     private static final TextLayout REUSABLE_INSTANCE = FACTORY.createLayout();
> 37:     private static final AtomicBoolean GUARD = new AtomicBoolean(false);

Minor: IN_USE might be a better name.

modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 45:

> 43:     int script;
> 44:     TextSpan span;
> 45:     com.sun.javafx.scene.text.TextLine line;

I recommend an import rather than listing the fully-qualified class here and below.

modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontResource.java line 99:

> 97:         if (bold == null) {
> 98:             String name = font.getStyle();
> 99:             bold = name.toLowerCase(Locale.US).contains("bold");

Should this be `Locale.ROOT` or does it really need to be `Locale.US`?

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2714620831
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012620345
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012660760
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012603455
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012605436
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012731466
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012734374
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012742406
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012853062

From mfox at openjdk.org  Tue Mar 25 20:50:19 2025
From: mfox at openjdk.org (Martin Fox)
Date: Tue, 25 Mar 2025 20:50:19 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <OM3lOQh4sJBDaKGVy8R3ARDZnRXB2Ned-E-AO5Ae_cg=.369ee3de-28a5-4ec6-8a02-a05d62356e32@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

For customers creating cross-platform apps having the limit be the same on all platforms would simplify testing. If this was per-platform we would need to publish the limits since developers would want to test on the most restrictive platform. And my guess is that we would set Mac and Windows to be close to the same (around 240) and Linux would be the outlier. So I'm leaning toward a cross-platform limit.

With that said documenting a cross-platform limit is awkward. Why is there a limit and why is it 240? There's one reason on the Mac, a different one on Windows, and Linux is just following the lead of the other two. In the cross-platform version of this PR I included a public constant but didn't even try to explain where the number came from. I'm tempted to make this non-public but have it show up in the exception description.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752509820

From angorya at openjdk.org  Tue Mar 25 20:53:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 20:53:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <8R8aEaOT0jIPyed4mz4oNl1eZSwB1gOyvWpTLZWVmNU=.ecc73aa3-57e0-4661-a9ab-87573f6e4565@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

Related mailing list discussion:
https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/053011.html

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752517163

From angorya at openjdk.org  Tue Mar 25 21:02:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 21:02:16 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v3]
In-Reply-To: <7KnTUmweRxFxnS7khi8yrXC3rd2A0G1fYyfcEm9FcgI=.cf44cfa3-ca45-4817-82b5-418d6411c5f9@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <o1ZEKTgBcTSJbMbQn9DMKBoDH3K3j6YkDt9SZB0O6k4=.d9a2b80e-3e8d-45fe-9673-256954913581@github.com>
 <Nx9HtM5yLtvQQbq5RKdNj-CJ41LKSfQpNrBe1Lmt3XY=.422e17f9-9e05-45e1-8a41-9e0242ada87d@github.com>
 <79IKUuPhYjohM2uFtS1PEM8d2ZjjlBld26U5vuOX_wQ=.6795bca3-a4a1-4f56-90ae-57f1bf71182c@github.com>
 <oRAGtUmsleTm934fst11fuOjTCze5BUbdX97yRdS5o8=.ee928315-562e-4ddf-bb42-79816f26a16f@github.com>
 <XZ9nm2syOCghJJXaFXcm2JTgRXY51O5AO922XM3BHyA=.0c497bc5-6dcc-4aeb-bb97-245047e9acbf@github.com>
 <7KnTUmweRxFxnS7khi8yrXC3rd2A0G1fYyfcEm9FcgI=.cf44cfa3-ca45-4817-82b5-418d6411c5f9@github.com>
Message-ID: <noNIffs8ko7QRKgMagZLpqJKtOSQ5yrKeT86XsOS4zQ=.148dcb9e-5b3d-40fe-b052-67ffd13ca7ca@github.com>

On Tue, 25 Mar 2025 14:53:25 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> The font and size are not applied

Thank you, the screenshot helped!

The problem was in the way HTML text was copied to Outlook (for some reason, Outlook prioritizes HTML over RTF when pasting).  The font sizes in HTML were using points (`pt.`) instead of pixels (`px.`).

In addition to that, copying to HTML did not process boolean attributes correctly.

Thank you for finding these issues!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2752533627

From kcr at openjdk.org  Tue Mar 25 21:06:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 21:06:17 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <nlAl80sSHbo4mw_YqKCWJaW1FW5Q_zPIdWJlT6lC_EM=.70c4be9e-b965-4e95-901b-86558d4a404b@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

I can see the benefit of a cross-platform limit. And a limit is 240, or even 200, is way more than should be needed for a reasonable application.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2752542829

From angorya at openjdk.org  Tue Mar 25 21:39:57 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 21:39:57 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v4]
In-Reply-To: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
Message-ID: <UbUDE7S__TNYd3XLrv5G8D94FJbU40nX8YgnnrrPGe8=.583be61e-6c9e-4b4e-8239-cf5c51f01153@github.com>

> Fixed several issues found in importing RTF text:
> 
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
> 
> Also, HTML copy suffered from the following issues:
> 
> - incorrect font size
> - incorrect handling of boolean character attributes (bold, italic, etc.)
> 
> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
> 
> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - html
 - Merge remote-tracking branch 'origin/master' into 8351878.rtf
 - arabic
 - whitespace
 - test
 - strikethrough
 - missing code in attr set
 - font size
 - fixed arabic import

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1735/files
  - new: https://git.openjdk.org/jfx/pull/1735/files/f7834f61..63dbbb3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=02-03

  Stats: 654 lines in 15 files changed: 584 ins; 31 del; 39 mod
  Patch: https://git.openjdk.org/jfx/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1735/head:pull/1735

PR: https://git.openjdk.org/jfx/pull/1735

From angorya at openjdk.org  Tue Mar 25 21:44:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 21:44:23 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
 <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
Message-ID: <8l_vkaWAiHvJEWmXIkvO683x9zwOlEY8nKI-oYi3-BE=.f2e9ade7-77c5-4ddc-a50f-94708b6c97ee@github.com>

On Tue, 25 Mar 2025 17:43:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "fixed bad merge"
>>   
>>   This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/chart/StackedBarChartTest.java line 116:
> 
>> 114:         String bounds = computeBoundsString((Region)childrenList.get(0), (Region)childrenList.get(1),
>> 115:                 (Region)childrenList.get(2));
>> 116:         assertEquals("10 440 216 34 236 397 216 77 461 345 216 129 ", bounds);
> 
> I presume these changes are needed because they are also hard-coded values that are changing with the StubToolkit changes?

correct

> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 100:
> 
>> 98: import test.com.sun.javafx.scene.control.test.RT_22463_Person;
>> 99: 
>> 100: /**
> 
> Minor: We don't typically use javadoc-style comments in the class docs of test classes, but since we have a global RFE to address this, I don't think it matters all that much.

I usually do javadoc comments, because they show up in Eclipse when I click on the class name.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012978540
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012980256

From angorya at openjdk.org  Tue Mar 25 21:55:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 21:55:54 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v10]
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:

 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Revert "fixed bad merge"
   
   This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
 - fixed bad merge
 - review comments
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
 - review comments
 - ... and 20 more: https://git.openjdk.org/jfx/compare/bae7ba7a...ad193db5

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1667/files
  - new: https://git.openjdk.org/jfx/pull/1667/files/e18e49a5..ad193db5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=09
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1667&range=08-09

  Stats: 2034 lines in 44 files changed: 1724 ins; 115 del; 195 mod
  Patch: https://git.openjdk.org/jfx/pull/1667.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1667/head:pull/1667

PR: https://git.openjdk.org/jfx/pull/1667

From kcr at openjdk.org  Tue Mar 25 21:55:54 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 21:55:54 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <8l_vkaWAiHvJEWmXIkvO683x9zwOlEY8nKI-oYi3-BE=.f2e9ade7-77c5-4ddc-a50f-94708b6c97ee@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
 <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
 <8l_vkaWAiHvJEWmXIkvO683x9zwOlEY8nKI-oYi3-BE=.f2e9ade7-77c5-4ddc-a50f-94708b6c97ee@github.com>
Message-ID: <Zxz17qmdn2rfKkVVXEk3l7I57XFg_3mrP231kJhztGg=.e320ea9f-3b6f-4d0c-972a-e61ea4388ed9@github.com>

On Tue, 25 Mar 2025 21:41:14 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListViewTest.java line 100:
>> 
>>> 98: import test.com.sun.javafx.scene.control.test.RT_22463_Person;
>>> 99: 
>>> 100: /**
>> 
>> Minor: We don't typically use javadoc-style comments in the class docs of test classes, but since we have a global RFE to address this, I don't think it matters all that much.
>
> I usually do javadoc comments, because they show up in Eclipse when I click on the class name.

OK. We'll figure out how to address this if and when we add jtreg support.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012983246

From angorya at openjdk.org  Tue Mar 25 21:55:54 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 21:55:54 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
 <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
Message-ID: <xlz5qB1q-OdXJ25JJBxCxxmK4b3tEn3Pi1NnTsJC36E=.28bf5057-2823-46fa-b359-38f87f9eddab@github.com>

On Tue, 25 Mar 2025 18:36:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "fixed bad merge"
>>   
>>   This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/text/PrismTextLayout.java line 57:
> 
>> 55:  * Prism TextLayout
>> 56:  */
>> 57: public abstract class PrismTextLayout implements TextLayout {
> 
> Minor: Instead of making this abstract, did you consider leaving it concrete, overriding the methods you need in StubTextLayout? It's fine to leave the change as you have it.

let's see if it works

> modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 45:
> 
>> 43:     int script;
>> 44:     TextSpan span;
>> 45:     com.sun.javafx.scene.text.TextLine line;
> 
> I recommend an import rather than listing the fully-qualified class here and below.

the problem is that we have `com.sun.javafx.text.TextLine implements com.sun.javafx.scene.text.TextLine`

we probably should rename the concrete class to something like `PrismTextLine` for clarity, but that will create a much larger diff.

> modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontResource.java line 99:
> 
>> 97:         if (bold == null) {
>> 98:             String name = font.getStyle();
>> 99:             bold = name.toLowerCase(Locale.US).contains("bold");
> 
> Should this be `Locale.ROOT` or does it really need to be `Locale.US`?

Locale.ROOT is probably a better choice.  the main reason is to avoid unexpected conversion in non-English locales.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012989686
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012985556
PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2012987712

From kcr at openjdk.org  Tue Mar 25 22:11:24 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 22:11:24 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v9]
In-Reply-To: <xlz5qB1q-OdXJ25JJBxCxxmK4b3tEn3Pi1NnTsJC36E=.28bf5057-2823-46fa-b359-38f87f9eddab@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <DRVjGL-4E03LBCvhmSgIdnlqLVQ25tgNgM8R7Elc-C4=.4c64a3e5-c9dd-40cb-b71d-de1b498ec7d0@github.com>
 <fAIUL5yTTapzzmBK_rDT9X-gPuPxhaC6f3TqjQq7yPc=.48b0ef77-ac4e-44e8-ab05-d10601be9e52@github.com>
 <xlz5qB1q-OdXJ25JJBxCxxmK4b3tEn3Pi1NnTsJC36E=.28bf5057-2823-46fa-b359-38f87f9eddab@github.com>
Message-ID: <7mzai5OWe4UkyN8lUr1gZaPzi6jR78OOfMOYpL5ngXo=.dd1dd030-a0b7-4ef1-833a-589cda7dff66@github.com>

On Tue, 25 Mar 2025 21:46:51 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/text/TextRun.java line 45:
>> 
>>> 43:     int script;
>>> 44:     TextSpan span;
>>> 45:     com.sun.javafx.scene.text.TextLine line;
>> 
>> I recommend an import rather than listing the fully-qualified class here and below.
>
> the problem is that we have `com.sun.javafx.text.TextLine implements com.sun.javafx.scene.text.TextLine`
> 
> we probably should rename the concrete class to something like `PrismTextLine` for clarity, but that will create a much larger diff.

Yes, that might be a good cleanup task on its own, but best to leave it alone for this PR.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1667#discussion_r2013003349

From kcr at openjdk.org  Tue Mar 25 22:11:23 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 22:11:23 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v10]
In-Reply-To: <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
Message-ID: <lRQiA6Yh3wSC3DQto9UB34TBpY3kTYBveZWtej2IIgQ=.34707571-fc81-43cb-9552-c3a71fb7fa2f@github.com>

On Tue, 25 Mar 2025 21:55:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Revert "fixed bad merge"
>    
>    This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
>  - fixed bad merge
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - review comments
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/c305766e...ad193db5

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2715314035

From zelmidaoui at openjdk.org  Tue Mar 25 22:28:35 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 22:28:35 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
Message-ID: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>

With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess

-------------

Commit messages:
 - Replaced reflection with direct calls to enableNativeAccess.

Changes: https://git.openjdk.org/jfx/pull/1743/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340004
  Stats: 16 lines in 2 files changed: 0 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1743.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1743/head:pull/1743

PR: https://git.openjdk.org/jfx/pull/1743

From angorya at openjdk.org  Tue Mar 25 22:44:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 22:44:21 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
In-Reply-To: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
Message-ID: <_GBgcXsaw4VmQS4OLGW125SmKeJnndxV7I7lbdo_seM=.cd2f2be5-07de-4a67-aebb-3bef5b2e24a3@github.com>

On Tue, 25 Mar 2025 22:24:51 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess

looks good!

please update the copyright year in the modified files.
1 reviewer is probably enough.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1743#pullrequestreview-2715361077

From zelmidaoui at openjdk.org  Tue Mar 25 22:53:55 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 22:53:55 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <iq7H_FFh4mFrERP6kpkDlkdSMFcV4mB5YdLGrHKf3W8=.bab8ad81-656e-48c0-8414-f2c4fdfec9ef@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <Ieb_X7SRc5_KUnwT_LCZlJoU_P9eJIxtF8FFmIQwi_I=.2ab842aa-413d-4243-9ab4-2b32b191c9a2@github.com>
 <EJnVMxaHetVEVKdZAf4IgkhTyk5j-8V6MCPzLte2kRs=.1d60d3e1-9841-419d-ad23-eec3f5b14488@github.com>
 <iq7H_FFh4mFrERP6kpkDlkdSMFcV4mB5YdLGrHKf3W8=.bab8ad81-656e-48c0-8414-f2c4fdfec9ef@github.com>
Message-ID: <3hWZlhKJrY5vEBdSHcj3K8FRM502kiE7LVYWuiwUGRg=.39cdc851-5877-464d-ac3b-bb4d168f4d06@github.com>

On Fri, 14 Mar 2025 16:27:09 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> With the new approach the `promptText` property is accepting any value so it's expected to have prompt text with Linebreaks for `TextField` and `PasswordField`, is this the test that I have to keep ?
>> 
>> Else to have a test that uses `stage` in `TextInputControlTest` we will have to check for the Class type in many cases since `TextInputSkinShim::getPromptNode` have two overloaded methods for `TextArea` and `TextField`
>> It will look like this in the test :
>> 
>> 
>>         SkinBase<?> skin;
>>         if (type.equals(TextField.class)) {
>>             textInput = new TextField();
>>             skin = new TextFieldSkin((TextField) textInput);
>>         } else if (type.equals(PasswordField.class)) {
>>             textInput = new PasswordField();
>>             skin = new TextFieldSkin((TextField) textInput);
>>         } else if (type.equals(TextArea.class)) {
>>             textInput = new TextArea();
>>             skin = new TextAreaSkin((TextArea) textInput);
>>         }
>> 
>> //test logic
>> 
>> if (type.equals(TextField.class) || type.equals(PasswordField.class)) {
>>             promptNode = TextInputSkinShim.getPromptNode((TextField) textInput);
>>         } else {
>>             promptNode = TextInputSkinShim.getPromptNode((TextArea) textInput);
>>         }
>
> If the code gets more complicated it might be better to use your initial approach and move the tests into separate classes (but remember the PasswordField lost its test cases - this might be ok since the methods and the logic being tested is identical between `TextField` and `PasswordField`).
> 
> Another option, for the sake of discussion, is to use a more complex parameter instead of simple `Class` for the parameterized test.  Take a look at the `LabelSkinCreationTest` - there the parameterized test iterates a list of `Parameters` which packs more data.  So you could, for example, supply more arguments to each test: the skin class, the getter, a flag that indicates whether the stage is needed, the expected string.
> 
> What do you think?

I guess we will keep it like this as you said since tested is identical between TextField and PasswordField

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2013039465

From zelmidaoui at openjdk.org  Tue Mar 25 22:53:55 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 22:53:55 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
Message-ID: <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>

> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
> Also fixed tests to meet the new changes

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused imports and code

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1716/files
  - new: https://git.openjdk.org/jfx/pull/1716/files/549c1997..4364489c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1716&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1716.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1716/head:pull/1716

PR: https://git.openjdk.org/jfx/pull/1716

From zelmidaoui at openjdk.org  Tue Mar 25 22:53:55 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Tue, 25 Mar 2025 22:53:55 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v3]
In-Reply-To: <gdZH3kUGnukYfzHoLDa6jUV43U2GFMOpwoo6Z2ihe3Q=.659c2a73-2d6c-46c3-98ae-bdbf275f710a@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <PunjkpgbPCkslbyjAOVVicfp3I2ht1EACldtcbc1E0g=.8a759507-f43e-4752-b62f-a090fa8025e9@github.com>
 <gdZH3kUGnukYfzHoLDa6jUV43U2GFMOpwoo6Z2ihe3Q=.659c2a73-2d6c-46c3-98ae-bdbf275f710a@github.com>
Message-ID: <YOHf6FELbLvq9fO9eYjcMNFbxkClJgOY6Hdu8KmG_Ng=.fd6e128a-1f40-4268-b536-1fe71d68eb36@github.com>

On Mon, 24 Mar 2025 16:59:43 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor changes
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 33:
> 
>> 31: import javafx.beans.binding.ObjectBinding;
>> 32: import javafx.beans.binding.StringBinding;
>> 33: import javafx.beans.binding.Bindings;
> 
> unused import can be removed

removed thanks

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 737:
> 
>> 735: 
>> 736:         promptNode.textProperty().bind(getSkinnable().promptTextProperty());
>> 737:         promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));
> 
> code in line 736 is not needed (we all missed that)

removed it also thanks

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2013038446
PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2013038870

From angorya at openjdk.org  Tue Mar 25 22:57:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Tue, 25 Mar 2025 22:57:13 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
Message-ID: <HorQKJiPOagFd4i-vwhbdq4DBcFq1ZYoj3uHbJ4Nxa4=.a75baf74-6278-4897-ae15-58b59669d83a@github.com>

On Tue, 25 Mar 2025 22:53:55 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports and code

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1716#pullrequestreview-2715377104

From lkostyra at openjdk.org  Wed Mar 26 07:36:21 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Wed, 26 Mar 2025 07:36:21 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v6]
In-Reply-To: <EwgssHEl4tDuqmnTLquybqO3iDfLh3EeVWChyv1mbiA=.6f1dc7cf-eea2-4711-93f5-638b2d98c710@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <EwgssHEl4tDuqmnTLquybqO3iDfLh3EeVWChyv1mbiA=.6f1dc7cf-eea2-4711-93f5-638b2d98c710@github.com>
Message-ID: <yeD0mou9nIjohRZKTbbWRc-Dir9F50NRCipa8cRih2E=.e6cffb78-2a86-4c0f-9d1b-ab20de80b782@github.com>

On Tue, 25 Mar 2025 18:39:08 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove non unicode textformats

Changes requested by lkostyra (Reviewer).

modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 207:

> 205: {
> 206:     addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
> 207:     addPair(GLASS_TEXT_PLAIN_LOCALE, CF_TEXT);

I would not remove them, rather replace CF_TEXT with CF_UNICODETEXT. We still need to support the MIMEs.

modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 210:

> 208:     addPair(GLASS_IMAGE, CF_JAVA_BITMAP);
> 209:     addPair(GLASS_FILE_LIST, CF_HDROP);
> 210:     addPair(MS_LOCALE, CF_LOCALE);

CF_LOCALE has to stay as CF_LOCALE - it is not a text format.

modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 211:

> 209:     addPair(GLASS_FILE_LIST, CF_HDROP);
> 210:     addPair(MS_LOCALE, CF_LOCALE);
> 211:     addPair(MS_OEMTEXT, CF_OEMTEXT);

As above - `s/CF_OEMTEXT/CF_UNICODETEXT`

-------------

PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2716134492
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2013535121
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2013537044
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2013537309

From mstrauss at openjdk.org  Wed Mar 26 08:33:20 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 26 Mar 2025 08:33:20 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <OM3lOQh4sJBDaKGVy8R3ARDZnRXB2Ned-E-AO5Ae_cg=.369ee3de-28a5-4ec6-8a02-a05d62356e32@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <OM3lOQh4sJBDaKGVy8R3ARDZnRXB2Ned-E-AO5Ae_cg=.369ee3de-28a5-4ec6-8a02-a05d62356e32@github.com>
Message-ID: <lAufYw_iigVyejJyz1ivp7RmTw_jFfxjZKWv_cAfXUs=.76c404bd-af0c-460f-973b-d18be6e7d05a@github.com>

On Tue, 25 Mar 2025 20:47:21 GMT, Martin Fox <mfox at openjdk.org> wrote:

> For customers creating cross-platform apps having the limit be the same on all platforms would simplify testing. If this was per-platform we would need to publish the limits since developers would want to test on the most restrictive platform.

Why would an application need to be tested against a specific limit? It seems the only thing that would be tested in this case is whether JavaFX works as advertised. An application that can conceivably start a nested event loop should always check whether it can start the event loop in the first place, and fail gracefully if it can't.

I can see some value in guaranteeing a lower limit for the number of nested event loops, which might be useful for applications that provably don't start more than a certain number of nested event loops.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2753585793

From mstrauss at openjdk.org  Wed Mar 26 08:37:16 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 26 Mar 2025 08:37:16 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
Message-ID: <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>

On Mon, 24 Mar 2025 18:30:56 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lower limit on run loop nesting

In any case, this PR should at least add the following bits of information to `Platform.enterNestedEventLoop()`:
1. There is some limit to the number of nested event loops.
2. Applications should always check `Platform.canStartNestedEventLoop()` before invoking `enterNestedEventLoop()`.
3. An exception will be thrown if the limit is exceeded.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2753594782

From mstrauss at openjdk.org  Wed Mar 26 08:47:24 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 26 Mar 2025 08:47:24 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
Message-ID: <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>

On Tue, 25 Mar 2025 22:53:55 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> Added multi line prompt support for TextArea this will provide the ability to have multiple lines in textArea as expected,
>> Also fixed tests to meet the new changes
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports and code

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 735:

> 733:         promptNode.fontProperty().bind(getSkinnable().fontProperty());
> 734: 
> 735:         promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));

I recommend to replace all usual newline characters with `replaceAll("[\r\n]", "")` as I can't think of a compelling reason to remove only some, but leave others in the string.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2013637092

From mhanl at openjdk.org  Wed Mar 26 12:15:16 2025
From: mhanl at openjdk.org (Marius Hanl)
Date: Wed, 26 Mar 2025 12:15:16 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v10]
In-Reply-To: <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
Message-ID: <IUaG-lr9_hodHa0uhm5T4s5YUDKhh7zNfiZdpEPJ6bc=.b4454aa7-8064-4201-84c2-60261891b387@github.com>

On Tue, 25 Mar 2025 21:55:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Revert "fixed bad merge"
>    
>    This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
>  - fixed bad merge
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - review comments
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/e5cd72b9...ad193db5

Newest changes look good as well.

-------------

Marked as reviewed by mhanl (Committer).

PR Review: https://git.openjdk.org/jfx/pull/1667#pullrequestreview-2716933889

From zelmidaoui at openjdk.org  Wed Mar 26 13:33:29 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Wed, 26 Mar 2025 13:33:29 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
Message-ID: <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>

On Wed, 26 Mar 2025 08:44:28 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused imports and code
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 735:
> 
>> 733:         promptNode.fontProperty().bind(getSkinnable().fontProperty());
>> 734: 
>> 735:         promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));
> 
> I recommend to replace all usual newline characters with `replaceAll("[\r\n]", "")` as I can't think of a compelling reason to remove only some, but leave others in the string.

The tests show that only LF "\n" is rendered as a new line, there is no need to add more restrictions that is not needed
and the same was tested by @andy-goryachev-oracle previously in the comments and it confirms the same.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2014152180

From mstrauss at openjdk.org  Wed Mar 26 14:14:19 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 26 Mar 2025 14:14:19 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
Message-ID: <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>

On Wed, 26 Mar 2025 13:30:48 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextFieldSkin.java line 735:
>> 
>>> 733:         promptNode.fontProperty().bind(getSkinnable().fontProperty());
>>> 734: 
>>> 735:         promptNode.textProperty().bind(getSkinnable().promptTextProperty().map(s -> s.replace("\n", "")));
>> 
>> I recommend to replace all usual newline characters with `replaceAll("[\r\n]", "")` as I can't think of a compelling reason to remove only some, but leave others in the string.
>
> The tests show that only LF "\n" is rendered as a new line, there is no need to add more restrictions that is not needed
> and the same was tested by @andy-goryachev-oracle previously in the comments and it confirms the same.

That doesn't sound like a compelling reason to me. In fact, it makes it seems like a bug in JavaFX that a line break is only rendered with `\n`, but not with `\r\n` or `\r`.

In any case, the goal here is to (semantically) transform a string such that it doesn't contain line breaks, and line breaks come in three different usual forms. Our goal should always be to do the right thing, and not stop half-way and rely on unspecified rendering quirks for the rest.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2014250131

From angorya at openjdk.org  Wed Mar 26 14:24:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 14:24:20 GMT
Subject: RFR: 8342565: [TestBug] StubTextLayout [v10]
In-Reply-To: <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
 <1VJSM42_Lq6fI7rUPakz1Fm2YI32CkrFvYn55o8AS4I=.a2d89ed5-7900-4a6e-803a-108548044470@github.com>
Message-ID: <9ow2Cp1n90UM18wDIU5QrzUzxmVOy8xx2jW-3I7ca7Q=.35553a47-cf53-439b-8fa7-c2707d8f1d7d@github.com>

On Tue, 25 Mar 2025 21:55:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
>> 
>> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
>> 
>> Existing tests have been adjusted/reworked mainly due to default font size change.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
> 
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Revert "fixed bad merge"
>    
>    This reverts commit 0e9e8ee63895bd1d976398587add5b96958d38aa.
>  - fixed bad merge
>  - review comments
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - Merge remote-tracking branch 'origin/master' into 8342565.stub.text.layout
>  - review comments
>  - ... and 20 more: https://git.openjdk.org/jfx/compare/29e942ca...ad193db5

thank you all for the review!

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1667#issuecomment-2754597376

From angorya at openjdk.org  Wed Mar 26 14:24:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 14:24:21 GMT
Subject: Integrated: 8342565: [TestBug] StubTextLayout
In-Reply-To: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
References: <AexS0_ToImXkMXWn4zYd6FbrshL6wlcVBAH4ypks0LQ=.766aef53-83ea-42e1-8a64-dbbb906fea95@github.com>
Message-ID: <QjBKLYEuwBFwQmE1aoGvRZNlm8Ve3iLRubv7QQHWYrM=.b1f54365-0445-46b7-b3de-9cccda7a939a@github.com>

On Fri, 20 Dec 2024 22:23:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Changed the StubTextLayout to use product PrismTextLayout with much simplified glyph layout (via stubbed fonts).  The new layout assumes all the glyphs are squares of font size, while the bold type face produces wider glyphs (by 1 pixel).  The default font size has changed from 10 to 12 to make it closer to win/linux.
> 
> This brings the test environment closer to the product configuration and expands the capabilities of our headless testing pipeline, which will be useful for upcoming behavior tests.
> 
> Existing tests have been adjusted/reworked mainly due to default font size change.

This pull request has now been integrated.

Changeset: 91433775
Author:    Andy Goryachev <angorya at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/91433775e75c9c662774f28de5310eab7da0fe7e
Stats:     1169 lines in 35 files changed: 680 ins; 281 del; 208 mod

8342565: [TestBug] StubTextLayout

Reviewed-by: mhanl, kcr

-------------

PR: https://git.openjdk.org/jfx/pull/1667

From angorya at openjdk.org  Wed Mar 26 14:33:37 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 14:33:37 GMT
Subject: RFR: 8341670: [Text,
 TextFlow] Public API for Text Layout Info [v22]
In-Reply-To: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
References: <6kU74wiGo1qbQaX9pCfr9Q5QRPoly_eXGGhVm9qt-e8=.d8d70e9f-96bb-4c89-aa02-de07adb94a82@github.com>
Message-ID: <vaskhWFL2y2ALfHGbmf_fmCoF5b6ZV2abfKsXD5nShU=.89f6c1e0-6e50-44d4-80a7-3d3e2d8709da@github.com>

> Please refer to
> 
> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/Text/LayoutInfo.md
> 
> The RichTextArea control ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom control that needs non-trivial navigation within complex or wrapped text needs a public API to get information about text layout.
> 
> This change fixes the missing functionality by adding a new public method to the `Text` and `TextFlow` classes.:
> 
> 
>     /**
>      * Obtains the snapshot of the current text layout information.
>      * @return the layout information
>      * @since 25
>      */
>     public final LayoutInfo getLayoutInfo()
> 
> 
> The `LayoutInfo` provides a view into the text layout within `Text`/`TextFlow` nodes such as:
> 
> - caret information
> - text lines: offsets and bounds
> - overall layout bounds
> - text selection geometry
> - strike-through geometry
> - underline geometry
> 
> 
> This PR also adds the missing `strikeThroughShape()` method to complement the existing `underlineShape()` and `rangeShape()` for consistency sake:
> 
> 
>     /**
>      * Returns the shape for the strike-through in local coordinates.
>      *
>      * @param start the beginning character index for the range
>      * @param end the end character index (non-inclusive) for the range
>      * @return an array of {@code PathElement} which can be used to create a {@code Shape}
>      * @since 25
>      */
>     public final PathElement[] strikeThroughShape(int start, int end)
> 
> 
> 
> 
> ## WARNING
> 
> Presently, information obtained via certain Text/TextField methods is incorrect with non-zero padding and borders, see [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438).
> 
> This PR provides correct answers in the new API, leaving the behavior of the existing methods unchanged (there is a compatibility risk associated with trying to fix [JDK-8341438](https://bugs.openjdk.org/browse/JDK-8341438) ).
> 
> 
> 
> ## Testing
> 
> The new APIs can be visually tested using the Monkey Tester on this branch:
> https://github.com/andy-goryachev-oracle/MonkeyTest/tree/text.layout.api
> 
> in the Text and TextFlow pages:
> ![Screenshot 2024-11-04 at 11 38 21](https://github.com/user-attachments/assets/2e17e55c-f819-4742-8a42-b9af2b6bac72)
> 
> Two very basic headful tests have been added.
> 
> 
> ## See Also
> 
> https://github.com/FXMisc/RichTextFX/pull/1246

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - twice
 - tests
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - review comments
 - Merge remote-tracking branch 'origin/master' into ag.text.layout.api
 - 25 25
 - Merge branch 'master' into ag.text.layout.api
 - ... and 37 more: https://git.openjdk.org/jfx/compare/91433775...9cee2dc7

-------------

Changes: https://git.openjdk.org/jfx/pull/1596/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1596&range=21
  Stats: 1538 lines in 13 files changed: 1476 ins; 18 del; 44 mod
  Patch: https://git.openjdk.org/jfx/pull/1596.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1596/head:pull/1596

PR: https://git.openjdk.org/jfx/pull/1596

From angorya at openjdk.org  Wed Mar 26 14:36:39 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 14:36:39 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
Message-ID: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>

> Fixed several issues found in importing RTF text:
> 
> - charset translation (brought back removed code)
> - missing font size attribute
> - missing strike-through attribute
> 
> Also, HTML copy suffered from the following issues:
> 
> - incorrect font size
> - incorrect handling of boolean character attributes (bold, italic, etc.)
> 
> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
> 
> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into 8351878.rtf
 - html
 - Merge remote-tracking branch 'origin/master' into 8351878.rtf
 - arabic
 - whitespace
 - test
 - strikethrough
 - missing code in attr set
 - font size
 - fixed arabic import

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1735/files
  - new: https://git.openjdk.org/jfx/pull/1735/files/63dbbb3d..6a89c153

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1735&range=03-04

  Stats: 2187 lines in 49 files changed: 1516 ins; 332 del; 339 mod
  Patch: https://git.openjdk.org/jfx/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1735/head:pull/1735

PR: https://git.openjdk.org/jfx/pull/1735

From angorya at openjdk.org  Wed Mar 26 14:46:07 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 14:46:07 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v5]
In-Reply-To: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
Message-ID: <djPPtfzJbhsufwKoYdH5ESH6kZ0vjMA9ODT2Z-vXwvM=.26696603-f5f9-4ca4-9872-418495830bc4@github.com>

> Additional RichTextArea API tests.

Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into 8347359.rta.api.tests
 - review comments
 - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into
   8347359.rta.api.tests
 - newlines
 - check
 - ... and 13 more: https://git.openjdk.org/jfx/compare/91433775...c0cde4a9

-------------

Changes: https://git.openjdk.org/jfx/pull/1677/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1677&range=04
  Stats: 1383 lines in 10 files changed: 1323 ins; 29 del; 31 mod
  Patch: https://git.openjdk.org/jfx/pull/1677.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1677/head:pull/1677

PR: https://git.openjdk.org/jfx/pull/1677

From mfox at openjdk.org  Wed Mar 26 17:13:25 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 26 Mar 2025 17:13:25 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v3]
In-Reply-To: <lAufYw_iigVyejJyz1ivp7RmTw_jFfxjZKWv_cAfXUs=.76c404bd-af0c-460f-973b-d18be6e7d05a@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <OM3lOQh4sJBDaKGVy8R3ARDZnRXB2Ned-E-AO5Ae_cg=.369ee3de-28a5-4ec6-8a02-a05d62356e32@github.com>
 <lAufYw_iigVyejJyz1ivp7RmTw_jFfxjZKWv_cAfXUs=.76c404bd-af0c-460f-973b-d18be6e7d05a@github.com>
Message-ID: <JwVGM-wpFX3Oj7paDTkBPxm1X5mQ-zpY9mXF9lBu6Co=.94c05e46-dfc7-4d29-832e-27b12a5f9ff0@github.com>

On Wed, 26 Mar 2025 08:30:08 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Why would an application need to be tested against a specific limit?

If you knew that your app could hit a limit and the limit could vary by platform you would want to focus your testing on the platform with the lowest limit. In any case it's always annoying when a program works on one platform and fails on another. Better to have it fail the same way everywhere if possible (and in this case we can make that happen).

> An application that can conceivably start a nested event loop should always check whether it can start the event loop in the first place, and fail gracefully if it can't.

This would require adding checks before any calls that start a nested event loop. In the test case submitted by the customer the check would have to occur before a call to `Stage.showAndWait`. On the Mac a nested event loop is entered whenever the fullscreen state changes. I don't think there's any good way for a developer to know which JavaFX calls might enter a nested event loop.

As far as we know this crash is triggered when the app enters an unexpected state of runaway recursion. I think the goal is to keep the system from crashing long enough to get a Java stack trace to understand how the system got into that state. In the case submitted by the customer the stack trace suggests that JavaFX is throwing an exception that it should not be throwing (I was able to reproduce the recursive state but am still sorting through the rubble).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2755141407

From martinfox656 at gmail.com  Wed Mar 26 17:33:26 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 26 Mar 2025 10:33:26 -0700
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
Message-ID: <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>

Yes, thank you Christopher for providing a reproducible test case!

I was able to trigger the problem on my Mac on the first try. Since I?m using a modified version of JavaFX the system didn?t crash but instead hit a Java stack overflow error and produced a very long stack trace.

At least on the Mac the problem seems to be that you?re trying to pop an Alert containing a long stack trace. While trying to adjust the Alert?s bounds JavaFX is throwing another exception but I?m not sure why. I?ll continue to look into it.

Thanks again,
Martin

> On Mar 25, 2025, at 12:16?PM, Andy Goryachev <andy.goryachev at oracle.com> wrote:
> 
> Thank you, Christopher, for clarification!
>  
> Personally, I would consider this to be a problem with the application design: the code should limit the number of alerts shown to the user.  Do you really want the user to click through hundreds of alerts?
>  
> Nevertheless, you are right about the need for the platform to gracefully handle the case of too many nested event loops - by throwing an exception with a meaningful message, as Martin proposed in https://github.com/openjdk/jfx/pull/1741
>  
> Cheers,
> -andy
>  
>  
>  
> From: Christopher Schnick <crschnick at xpipe.io>
> Date: Tuesday, March 25, 2025 at 11:52
> To: Andy Goryachev <andy.goryachev at oracle.com>
> Cc: OpenJFX <openjfx-dev at openjdk.org>
> Subject: Re: [External] : Re: JVM crashes on macOS when entering too many nested event loops
> 
> Hey Andy,
> 
> so I think I was able to reproduce this issue for our application.
> 
> There are two main factors how this can happen:
> - We use an alert-based error reporter, meaning that we have a default uncaught exception handler set for all threads which will showAndWait an Alert with the exception message
> - As I reported yesterday with https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, there are some rare exceptions that can occur in a normal event loop without interference of the application, probably because of a small bug in the bounds calculation code
> 
> If you combine these two factors, you will end up with an infinite loop of the showAndWait entering a nested event loop, the event loop throwing an internal exception, and the uncaught exception handler starting the same loop with another alert. I don't think this is a bad implementation from our side, the only thing that we can improve is to maybe check how deep the uncaught exception loop is in to prevent this from occurring indefinitely. But I would argue this can happen to any application. Here is a sample code, based on the reproducer from the OutOfBounds report from yesterday:
> 
> import javafx.application.Application;
> import javafx.application.Platform;
> import javafx.scene.Scene;
> import javafx.scene.control.Alert;
> import javafx.scene.control.Button;
> import javafx.scene.layout.Region;
> import javafx.scene.layout.StackPane;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
>  
> import java.io.IOException;
> import java.util.Arrays;
>  
> public class ParentBoundsBug extends Application {
>  
>     @Override
>     public void start(Stage stage) throws IOException {
>         Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
>             throwable.printStackTrace();
>  
>             if (Platform.isFxApplicationThread()) {
>                 var alert = new Alert(Alert.AlertType.ERROR);
>                 alert.setHeaderText(throwable.getMessage());
>                 alert.setContentText(Arrays.toString(throwable.getStackTrace()));
>                 alert.showAndWait();
>             } else {
>                 // Do some other error handling for non-platform threads
>                 // Probably just show the alert with a runLater()
>  
>                 // For this example, there are no exceptions outside the platform thread
>             }
>         });
>  
>         // Run delayed as Application::reportException will only be called for exceptions
>         // after the application has started
>         Platform.runLater(() -> {
>             Scene scene = new Scene(createContent(), 640, 480);
>             stage.setScene(scene);
>             stage.show();
>             stage.centerOnScreen();
>         });
>     }
>  
>     private Region createContent() {
>         var b1 = new Button("Click me!");
>         var b2 = new Button("Click me!");
>         var vbox = new VBox(b1, b2);
>         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>             vbox.setVisible(!vbox.isVisible());
>         });
>         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>             vbox.setVisible(!vbox.isVisible());
>         });
>         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>             vbox.setVisible(!vbox.isVisible());
>         });
>  
>         var stack = new StackPane(vbox, new StackPane());
>         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>             vbox.setVisible(!vbox.isVisible());
>         });
>         return stack;
>     }
>  
>     public static void main(String[] args) {
>         launch();
>     }
> }
> 
> If the same OutOfBounds exception from the reported I linked happens in the bounds calculation, which happens approximately 1/5 runs for me, this application will enter new event loops until it crashes. If the OutOfBounds doesn't trigger, it will just throw a StackOverflow but won't continue the infinite loop of nested event loops. So for the reproducer it is important to try a few times until you get the described OutOfBounds.
> 
> I attached the stacktrace of how this fails. The initial StackOverflow causes infinitely many following exceptions in the nested event loop.
> 
> Best
> Christopher Schnick
> 
> On 25/03/2025 18:28, Andy Goryachev wrote:
> Dear Christopher:
>  
> Were you able to root cause why your application enters that many nested event loops?
>  
> I believe a well-behaved application should never experience that, unless there is some design flaw or a bug.
>  
> -andy
>  
>  
> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
> Date: Monday, March 10, 2025 at 19:45
> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
> Subject: [External] : Re: JVM crashes on macOS when entering too many nested event loops
> 
> Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.
> 
> I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
> From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
> And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.
> 
> Best
> Christopher Schnick
> 
> On 10/03/2025 18:51, Andy Goryachev wrote:
> This looks to me like it might be hitting the (native) thread stack size limit.
>  
> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>  
>      * An application may enter several nested loops recursively. There's no
>      * limit of recursion other than that imposed by the native stack size.
>  
>  
> -andy
>  
>  
>  
> From: openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
> Date: Monday, March 10, 2025 at 10:10
> To: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
> Subject: Re: JVM crashes on macOS when entering too many nested event loops
> 
> Hi Christopher,
> 
> I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
> I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.
> 
> Martin
> 
> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
> > 
> > Hello,
> > 
> > I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
> > 
> > As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
> > 
> > Best
> > Christopher Schnick<hs_err_pid.txt>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250326/3fc6bb6c/attachment-0001.htm>

From mfox at openjdk.org  Wed Mar 26 17:37:39 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 26 Mar 2025 17:37:39 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v4]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with two additional commits since the last revision:

 - Set limit on nested event loop count to 200 which seems less arbitrary
 - The max nested event loop limit is now platform-independent

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/0d44f217..b08594fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=03
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=02-03

  Stats: 78 lines in 7 files changed: 19 ins; 44 del; 15 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From mfox at openjdk.org  Wed Mar 26 17:46:35 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 26 Mar 2025 17:46:35 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v4]
In-Reply-To: <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
Message-ID: <B7rUqQP8yQ3ZQeh_vMR2upA_udB14TuUlHr47B65QKY=.c9ed726c-cdea-4d03-8ebe-b56e77b73590@github.com>

On Wed, 26 Mar 2025 17:37:39 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Set limit on nested event loop count to 200 which seems less arbitrary
>  - The max nested event loop limit is now platform-independent

I've updated this PR to remove the platform-specific code and impose a limit of 200 nested event loops everywhere. I added a public constant to Platform (is this the right place?). It's not clear that this needs to be that public, it might be enough for the number to show up in the exception description. A developer that hits the limit would want to know that it's not some arbitrarily small number.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2755279751

From crschnick at xpipe.io  Wed Mar 26 17:49:16 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Wed, 26 Mar 2025 18:49:16 +0100
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
Message-ID: <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>

Hey Martin,

thank you for looking into this. The initial StackOverflow is a result 
of me forcing to reproduce the bounds IndexOutOfBoundsException. The 
StackOverflow can be ignored, it was merely the best method I found to 
transition the scene graph into a state where the 
IndexOutOfBoundsExceptions are thrown. The OOBs are not thrown in every 
run though, it sometimes takes a few tries. In our production 
application, the same IndexOutOfBoundsExceptions also occur randomly 
without a previous exception. You can probably also reproduce the 
IndexOutOfBoundsExceptions without the StackOverflow, but reproducing it 
was very fragile, so I didn't look into it more.

I don't think it has necessarily something to do with the alert bounds 
as the IndexOutOfBoundsException is also thrown if you don't show an 
alert at all. The constant IndexOutOfBoundsExceptions in combination 
with the alert showAndWait was how our application entered the original 
crashing state. So the reproducer is more like a two-in-one.

Best
Christopher Schnick

On 26/03/2025 18:33, Martin Fox wrote:
> Yes, thank you Christopher for providing a reproducible test case!
>
> I was able to trigger the problem on my Mac on the first try. Since 
> I?m using a modified version of JavaFX the system didn?t crash but 
> instead hit a Java stack overflow error and produced a very long stack 
> trace.
>
> At least on the Mac the problem seems to be that you?re trying to pop 
> an Alert containing a long stack trace. While trying to adjust the 
> Alert?s bounds JavaFX is throwing another exception but I?m not sure 
> why. I?ll continue to look into it.
>
> Thanks again,
> Martin
>
>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev 
>> <andy.goryachev at oracle.com> wrote:
>>
>> Thank you, Christopher, for clarification!
>> Personally, I would consider this to be a problem with the 
>> application design: the code should limit the number of alerts shown 
>> to the user.? Do you really want the user to click through hundreds 
>> of alerts?
>> Nevertheless, you are right about the need for the platform to 
>> gracefully handle the case of too many nested event loops - by 
>> throwing an exception with a meaningful message, as Martin proposed 
>> inhttps://github.com/openjdk/jfx/pull/1741
>> Cheers,
>> -andy
>>
>> *From:*Christopher Schnick <crschnick at xpipe.io>
>> *Date:*Tuesday, March 25, 2025 at 11:52
>> *To:*Andy Goryachev <andy.goryachev at oracle.com>
>> *Cc:*OpenJFX <openjfx-dev at openjdk.org>
>> *Subject:*Re: [External] : Re: JVM crashes on macOS when entering too 
>> many nested event loops
>>
>> Hey Andy,
>>
>> so I think I was able to reproduce this issue for our application.
>>
>> There are two main factors how this can happen:
>> - We use an alert-based error reporter, meaning that we have a 
>> default uncaught exception handler set for all threads which will 
>> showAndWait an Alert with the exception message
>> - As I reported yesterday 
>> withhttps://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, 
>> there are some rare exceptions that can occur in a normal event loop 
>> without interference of the application, probably because of a small 
>> bug in the bounds calculation code
>>
>> If you combine these two factors, you will end up with an infinite 
>> loop of the showAndWait entering a nested event loop, the event loop 
>> throwing an internal exception, and the uncaught exception handler 
>> starting the same loop with another alert. I don't think this is a 
>> bad implementation from our side, the only thing that we can improve 
>> is to maybe check how deep the uncaught exception loop is in to 
>> prevent this from occurring indefinitely. But I would argue this can 
>> happen to any application. Here is a sample code, based on the 
>> reproducer from the OutOfBounds report from yesterday:
>>
>> import javafx.application.Application;
>> import javafx.application.Platform;
>> import javafx.scene.Scene;
>> import javafx.scene.control.Alert;
>> import javafx.scene.control.Button;
>> import javafx.scene.layout.Region;
>> import javafx.scene.layout.StackPane;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>> import java.io.IOException;
>> import java.util.Arrays;
>> public class ParentBoundsBug extends Application {
>> @Override
>> public void start(Stage stage) throws IOException {
>> ??????? Thread./setDefaultUncaughtExceptionHandler/((thread, 
>> throwable) -> {
>> ??????????? throwable.printStackTrace();
>> if (Platform./isFxApplicationThread/()) {
>> var alert = new Alert(Alert.AlertType./ERROR/);
>> ??????????????? alert.setHeaderText(throwable.getMessage());
>> ??????????????? 
>> alert.setContentText(Arrays./toString/(throwable.getStackTrace()));
>> ??????????????? alert.showAndWait();
>> ??????????? } else {
>> // Do some other error handling for non-platform threads
>> ??????????????? // Probably just show the alert with a runLater()
>> ??????????????? // For this example, there are no exceptions outside 
>> the platform thread
>> }
>> ??????? });
>> // Run delayed as Application::reportException will only be called 
>> for exceptions
>> ??????? // after the application has started
>> Platform./runLater/(() -> {
>> ??????????? Scene scene = new Scene(createContent(), 640, 480);
>> stage.setScene(scene);
>> stage.show();
>> stage.centerOnScreen();
>> ??????? });
>> ??? }
>> private Region createContent() {
>> var b1 = new Button("Click me!");
>> var b2 = new Button("Click me!");
>> var vbox = new VBox(b1, b2);
>> ??????? b1.boundsInParentProperty().addListener((observable, 
>> oldValue, newValue) -> {
>> vbox.setVisible(!vbox.isVisible());
>> ??????? });
>> ??????? b2.boundsInParentProperty().addListener((observable, 
>> oldValue, newValue) -> {
>> vbox.setVisible(!vbox.isVisible());
>> ??????? });
>> ??????? vbox.boundsInParentProperty().addListener((observable, 
>> oldValue, newValue) -> {
>> vbox.setVisible(!vbox.isVisible());
>> ??????? });
>> var stack = new StackPane(vbox, new StackPane());
>> ??????? stack.boundsInParentProperty().addListener((observable, 
>> oldValue, newValue) -> {
>> vbox.setVisible(!vbox.isVisible());
>> ??????? });
>> return stack;
>> ??? }
>> public static void main(String[] args) {
>> /launch/();
>> ??? }
>> }
>>
>>
>> If the same OutOfBounds exception from the reported I linked happens 
>> in the bounds calculation, which happens approximately 1/5 runs for 
>> me, this application will enter new event loops until it crashes. If 
>> the OutOfBounds doesn't trigger, it will just throw a StackOverflow 
>> but won't continue the infinite loop of nested event loops. So for 
>> the reproducer it is important to try a few times until you get the 
>> described OutOfBounds.
>>
>> I attached the stacktrace of how this fails. The initial 
>> StackOverflow causes infinitely many following exceptions in the 
>> nested event loop.
>>
>> Best
>> Christopher Schnick
>>
>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>
>>     Dear Christopher:
>>     Were you able to root cause why your application enters that many
>>     nested event loops?
>>     I believe a well-behaved application should never experience
>>     that, unless there is some design flaw or a bug.
>>     -andy
>>
>>     *From:*Christopher Schnick<crschnick at xpipe.io>
>>     <mailto:crschnick at xpipe.io>
>>     *Date:*Monday, March 10, 2025 at 19:45
>>     *To:*Andy Goryachev<andy.goryachev at oracle.com>
>>     <mailto:andy.goryachev at oracle.com>
>>     *Subject:*[External] : Re: JVM crashes on macOS when entering too
>>     many nested event loops
>>
>>     Our code and some libraries do enter some nested event loops at a
>>     few places when it makes sense, but we didn't do anything to
>>     explicitly provoke this, this occurred naturally in our
>>     application. So it would be nice if JavaFX could somehow guard
>>     against this, especially since crashing the JVM is probably the
>>     worst thing that can happen.
>>
>>     I looked at the documentation, but it seems like the public API
>>     at Platform::enterNestedEventLoop does not mention this.
>>     From my understanding, the method
>>     Platform::canStartNestedEventLoop is potentially the right method
>>     to indicate to the caller that the limit is close by returning false.
>>     And even if something like an exception is thrown when a nested
>>     event loop is started while it is close to the limit, that would
>>     still be much better than a direct crash.
>>
>>     Best
>>     Christopher Schnick
>>
>>     On 10/03/2025 18:51, Andy Goryachev wrote:
>>
>>         This looks to me like it might be hitting the (native) thread
>>         stack size limit.
>>         c.s.glass.ui.Application::enterNestedEventLoop() even warns
>>         about it:
>>         * An application may enter several nested loops recursively.
>>         There's no
>>         * limit of recursion other than that imposed by the native
>>         stack size.
>>         -andy
>>
>>         *From:*openjfx-dev<openjfx-dev-retn at openjdk.org>
>>         <mailto:openjfx-dev-retn at openjdk.org>on behalf of Martin
>>         Fox<martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>         *Date:*Monday, March 10, 2025 at 10:10
>>         *To:*Christopher Schnick<crschnick at xpipe.io>
>>         <mailto:crschnick at xpipe.io>
>>         *Cc:*OpenJFX<openjfx-dev at openjdk.org>
>>         <mailto:openjfx-dev at openjdk.org>
>>         *Subject:*Re: JVM crashes on macOS when entering too many
>>         nested event loops
>>
>>         Hi Christopher,
>>
>>         I was able to reproduce this crash. I wrote a small routine
>>         that recursively calls itself in a runLater block and then
>>         enters a nested event loop. The program crashes when creating
>>         loop 254. I?m not sure where that limit comes from so it?s
>>         possible that consuming some other system resource could
>>         lower it. I couldn?t see any good way to determine how many
>>         loops are active by looking at the crash report since it
>>         doesn?t show the entire call stack.
>>         I did a quick trial on Linux and was able to create a lot
>>         more loops (over 600) but then started seeing erratic
>>         behavior and errors coming from the Java VM. The behavior was
>>         variable unlike on the Mac which always crashes when creating
>>         loop 254.
>>
>>         Martin
>>
>>         > On Mar 7, 2025, at 6:24?AM, Christopher
>>         Schnick<crschnick at xpipe.io> <mailto:crschnick at xpipe.io>wrote:
>>         >
>>         > Hello,
>>         >
>>         > I have attached a JVM fatal error log that seemingly was
>>         caused by our JavaFX application entering too many nested
>>         event loops, which macOS apparently doesn't like.
>>         >
>>         > As far as I know, there is no upper limit defined on how
>>         often an event loop can be nested, so I think this is a bug
>>         that can occur in rare situations.
>>         >
>>         > Best
>>         > Christopher Schnick<hs_err_pid.txt>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250326/f7cd0f83/attachment-0001.htm>

From angorya at openjdk.org  Wed Mar 26 18:20:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 18:20:23 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
 <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
Message-ID: <uZjdVJePu4oi2nzppbWjZayA98tO_WGONSFdrlcDsMI=.e8102e73-286c-42c3-a4c7-79840b093af8@github.com>

On Wed, 26 Mar 2025 14:11:34 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The tests show that only LF "\n" is rendered as a new line, there is no need to add more restrictions that is not needed
>> and the same was tested by @andy-goryachev-oracle previously in the comments and it confirms the same.
>
> That doesn't sound like a compelling reason to me. In fact, it makes it seems like a bug in JavaFX that a line break is only rendered with `\n`, but not with `\r\n` or `\r`.
> 
> In any case, the goal here is to (semantically) transform a string such that it doesn't contain line breaks, and line breaks come in three different usual forms. Our goal should always be to do the right thing, and not stop half-way and rely on unspecified rendering quirks for the rest.

We seem to have arrived at these two options:

1. acknowledge and defend the status quo in which the text layout considers only '\n' as newlines
2. enhance the text layout to handle other paragraph separators (as well as maybe add support for other symbols that impact layout, such as soft hyphen)

@kevinrushforth what do you think?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2014771096

From angorya at openjdk.org  Wed Mar 26 18:25:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 18:25:19 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v4]
In-Reply-To: <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
Message-ID: <KfDDsPOxpk7xK3jOrU1j10QIBDOXy_sgiEIqk5Wwwpg=.829b3624-4bd9-46a1-8092-219846c7b358@github.com>

On Wed, 26 Mar 2025 17:37:39 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Set limit on nested event loop count to 200 which seems less arbitrary
>  - The max nested event loop limit is now platform-independent

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 279:

> 277:      * @since 25
> 278:      */
> 279:     public static final int MAX_NESTED_EVENT_LOOPS = 200;

I would rather not make this constant public.  This is essentially a safeguard measure, with the main purpose to prevent the crash and give the indication to the application developer that their program has an issue.  From this perspective, the actual number is not important and should not be codified as a public API (but definitely declared as a constant internally).

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2014778827

From martinfox656 at gmail.com  Wed Mar 26 18:35:01 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Wed, 26 Mar 2025 11:35:01 -0700
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
Message-ID: <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>

Christopher,

Yes, there might be more than one issue here. On the Mac the call to Stage.showAndWait is making its way into the Mac glass code where an exception is being thrown leading to another call to Stage.showAndWait. I?ve attached the repeating block below. I don?t see that pattern in the Windows stack trace you provided.

Martin

	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
	at javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException(Application.java:452)
	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2(Native Method)
	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds(MacWindow.java:70)
	at javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds(Window.java:589)
	at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds(WindowStage.java:304)
	at javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply(Window.java:1566)
	at javafx.graphics at 25-internal/javafx.stage.Window.applyBounds(Window.java:1424)
	at javafx.graphics at 25-internal/javafx.stage.Window.adjustSize(Window.java:327)
	at javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene(Window.java:284)
	at javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated(Window.java:1215)
	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
	at javafx.graphics at 25-internal/javafx.stage.Window.setShowing(Window.java:1235)
	at javafx.graphics at 25-internal/javafx.stage.Window.show(Window.java:1250)
	at javafx.graphics at 25-internal/javafx.stage.Stage.show(Stage.java:272)
	at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Stage.java:427)
	at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(HeavyweightDialog.java:162)
	at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Dialog.java:347)
	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)

> On Mar 26, 2025, at 10:49?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Hey Martin,
> 
> thank you for looking into this. The initial StackOverflow is a result of me forcing to reproduce the bounds IndexOutOfBoundsException. The StackOverflow can be ignored, it was merely the best method I found to transition the scene graph into a state where the IndexOutOfBoundsExceptions are thrown. The OOBs are not thrown in every run though, it sometimes takes a few tries. In our production application, the same IndexOutOfBoundsExceptions also occur randomly without a previous exception. You can probably also reproduce the IndexOutOfBoundsExceptions without the StackOverflow, but reproducing it was very fragile, so I didn't look into it more.
> 
> I don't think it has necessarily something to do with the alert bounds as the IndexOutOfBoundsException is also thrown if you don't show an alert at all. The constant IndexOutOfBoundsExceptions in combination with the alert showAndWait was how our application entered the original crashing state. So the reproducer is more like a two-in-one.
> 
> Best
> Christopher Schnick
> 
> On 26/03/2025 18:33, Martin Fox wrote:
>> Yes, thank you Christopher for providing a reproducible test case!
>> 
>> I was able to trigger the problem on my Mac on the first try. Since I?m using a modified version of JavaFX the system didn?t crash but instead hit a Java stack overflow error and produced a very long stack trace.
>> 
>> At least on the Mac the problem seems to be that you?re trying to pop an Alert containing a long stack trace. While trying to adjust the Alert?s bounds JavaFX is throwing another exception but I?m not sure why. I?ll continue to look into it.
>> 
>> Thanks again,
>> Martin
>> 
>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>>> 
>>> Thank you, Christopher, for clarification!
>>>  
>>> Personally, I would consider this to be a problem with the application design: the code should limit the number of alerts shown to the user.  Do you really want the user to click through hundreds of alerts?
>>>  
>>> Nevertheless, you are right about the need for the platform to gracefully handle the case of too many nested event loops - by throwing an exception with a meaningful message, as Martin proposed in https://github.com/openjdk/jfx/pull/1741
>>>  
>>> Cheers,
>>> -andy
>>>  
>>>  
>>>  
>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>> Date: Tuesday, March 25, 2025 at 11:52
>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>> Subject: Re: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>> 
>>> Hey Andy,
>>> 
>>> so I think I was able to reproduce this issue for our application.
>>> 
>>> There are two main factors how this can happen:
>>> - We use an alert-based error reporter, meaning that we have a default uncaught exception handler set for all threads which will showAndWait an Alert with the exception message
>>> - As I reported yesterday with https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, there are some rare exceptions that can occur in a normal event loop without interference of the application, probably because of a small bug in the bounds calculation code
>>> 
>>> If you combine these two factors, you will end up with an infinite loop of the showAndWait entering a nested event loop, the event loop throwing an internal exception, and the uncaught exception handler starting the same loop with another alert. I don't think this is a bad implementation from our side, the only thing that we can improve is to maybe check how deep the uncaught exception loop is in to prevent this from occurring indefinitely. But I would argue this can happen to any application. Here is a sample code, based on the reproducer from the OutOfBounds report from yesterday:
>>> 
>>> import javafx.application.Application;
>>> import javafx.application.Platform;
>>> import javafx.scene.Scene;
>>> import javafx.scene.control.Alert;
>>> import javafx.scene.control.Button;
>>> import javafx.scene.layout.Region;
>>> import javafx.scene.layout.StackPane;
>>> import javafx.scene.layout.VBox;
>>> import javafx.stage.Stage;
>>>  
>>> import java.io.IOException;
>>> import java.util.Arrays;
>>>  
>>> public class ParentBoundsBug extends Application {
>>>  
>>>     @Override
>>>     public void start(Stage stage) throws IOException {
>>>         Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
>>>             throwable.printStackTrace();
>>>  
>>>             if (Platform.isFxApplicationThread()) {
>>>                 var alert = new Alert(Alert.AlertType.ERROR);
>>>                 alert.setHeaderText(throwable.getMessage());
>>>                 alert.setContentText(Arrays.toString(throwable.getStackTrace()));
>>>                 alert.showAndWait();
>>>             } else {
>>>                 // Do some other error handling for non-platform threads
>>>                 // Probably just show the alert with a runLater()
>>>  
>>>                 // For this example, there are no exceptions outside the platform thread
>>>             }
>>>         });
>>>  
>>>         // Run delayed as Application::reportException will only be called for exceptions
>>>         // after the application has started
>>>         Platform.runLater(() -> {
>>>             Scene scene = new Scene(createContent(), 640, 480);
>>>             stage.setScene(scene);
>>>             stage.show();
>>>             stage.centerOnScreen();
>>>         });
>>>     }
>>>  
>>>     private Region createContent() {
>>>         var b1 = new Button("Click me!");
>>>         var b2 = new Button("Click me!");
>>>         var vbox = new VBox(b1, b2);
>>>         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>             vbox.setVisible(!vbox.isVisible());
>>>         });
>>>         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>             vbox.setVisible(!vbox.isVisible());
>>>         });
>>>         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>             vbox.setVisible(!vbox.isVisible());
>>>         });
>>>  
>>>         var stack = new StackPane(vbox, new StackPane());
>>>         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>             vbox.setVisible(!vbox.isVisible());
>>>         });
>>>         return stack;
>>>     }
>>>  
>>>     public static void main(String[] args) {
>>>         launch();
>>>     }
>>> }
>>> 
>>> If the same OutOfBounds exception from the reported I linked happens in the bounds calculation, which happens approximately 1/5 runs for me, this application will enter new event loops until it crashes. If the OutOfBounds doesn't trigger, it will just throw a StackOverflow but won't continue the infinite loop of nested event loops. So for the reproducer it is important to try a few times until you get the described OutOfBounds.
>>> 
>>> I attached the stacktrace of how this fails. The initial StackOverflow causes infinitely many following exceptions in the nested event loop.
>>> 
>>> Best
>>> Christopher Schnick
>>> 
>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>> Dear Christopher:
>>>  
>>> Were you able to root cause why your application enters that many nested event loops?
>>>  
>>> I believe a well-behaved application should never experience that, unless there is some design flaw or a bug.
>>>  
>>> -andy
>>>  
>>>  
>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>> Date: Monday, March 10, 2025 at 19:45
>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>> Subject: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>> 
>>> Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.
>>> 
>>> I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
>>> From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
>>> And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.
>>> 
>>> Best
>>> Christopher Schnick
>>> 
>>> On 10/03/2025 18:51, Andy Goryachev wrote:
>>> This looks to me like it might be hitting the (native) thread stack size limit.
>>>  
>>> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>>>  
>>>      * An application may enter several nested loops recursively. There's no
>>>      * limit of recursion other than that imposed by the native stack size.
>>>  
>>>  
>>> -andy
>>>  
>>>  
>>>  
>>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>> Date: Monday, March 10, 2025 at 10:10
>>> To: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>> Subject: Re: JVM crashes on macOS when entering too many nested event loops
>>> 
>>> Hi Christopher,
>>> 
>>> I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
>>> I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.
>>> 
>>> Martin
>>> 
>>> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>> > 
>>> > Hello,
>>> > 
>>> > I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>>> > 
>>> > As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>>> > 
>>> > Best
>>> > Christopher Schnick<hs_err_pid.txt>
>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250326/f1a10263/attachment-0001.htm>

From mfox at openjdk.org  Wed Mar 26 18:48:14 2025
From: mfox at openjdk.org (Martin Fox)
Date: Wed, 26 Mar 2025 18:48:14 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v4]
In-Reply-To: <KfDDsPOxpk7xK3jOrU1j10QIBDOXy_sgiEIqk5Wwwpg=.829b3624-4bd9-46a1-8092-219846c7b358@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
 <KfDDsPOxpk7xK3jOrU1j10QIBDOXy_sgiEIqk5Wwwpg=.829b3624-4bd9-46a1-8092-219846c7b358@github.com>
Message-ID: <cF8QjdHJzXOsS5e2b57HU7btIz4WZz3umInkjh4i1dU=.d80f6f69-c98d-415d-96e7-ac832e13fb17@github.com>

On Wed, 26 Mar 2025 18:22:50 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Set limit on nested event loop count to 200 which seems less arbitrary
>>  - The max nested event loop limit is now platform-independent
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 279:
> 
>> 277:      * @since 25
>> 278:      */
>> 279:     public static final int MAX_NESTED_EVENT_LOOPS = 200;
> 
> I would rather not make this constant public.  This is essentially a safeguard measure, with the main purpose to prevent the crash and give the indication to the application developer that their program has an issue.  From this perspective, the actual number is not important and should not be codified as a public API (but definitely declared as a constant internally).
> 
> What do you think?

I don't think it needs to be public. If we privatize this constant I could use some guidance on where to place it so that the system test can access it. Currently there are two system tests that exercise nested event loops (PlatformTest.java and NestedEventLoopTest.java) and they only rely on public API's.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2014810809

From angorya at openjdk.org  Wed Mar 26 19:03:20 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 19:03:20 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v4]
In-Reply-To: <cF8QjdHJzXOsS5e2b57HU7btIz4WZz3umInkjh4i1dU=.d80f6f69-c98d-415d-96e7-ac832e13fb17@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <VXxQATrfDeg6GnVxPQgYljrc7oRofFBSyF9CkYxC348=.775bc692-0cdb-41b9-990b-0ca4bafa6fc6@github.com>
 <KfDDsPOxpk7xK3jOrU1j10QIBDOXy_sgiEIqk5Wwwpg=.829b3624-4bd9-46a1-8092-219846c7b358@github.com>
 <cF8QjdHJzXOsS5e2b57HU7btIz4WZz3umInkjh4i1dU=.d80f6f69-c98d-415d-96e7-ac832e13fb17@github.com>
Message-ID: <w2TmWiaUM-kih7XJAwczdo_V8L5HfngoqlWQwoRD0lw=.c78bf0f3-3df0-4917-a7ab-42ce30d89352@github.com>

On Wed, 26 Mar 2025 18:45:49 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 279:
>> 
>>> 277:      * @since 25
>>> 278:      */
>>> 279:     public static final int MAX_NESTED_EVENT_LOOPS = 200;
>> 
>> I would rather not make this constant public.  This is essentially a safeguard measure, with the main purpose to prevent the crash and give the indication to the application developer that their program has an issue.  From this perspective, the actual number is not important and should not be codified as a public API (but definitely declared as a constant internally).
>> 
>> What do you think?
>
> I don't think it needs to be public. If we privatize this constant I could use some guidance on where to place it so that the system test can access it. Currently there are two system tests that exercise nested event loops (PlatformTest.java and NestedEventLoopTest.java) and they only rely on public API's.

`PlatformImpl` is probably a good choice, and it's already configured to be accessible to the system tests via `tests/system/src/test/addExports`

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2014830866

From angorya at openjdk.org  Wed Mar 26 19:23:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 19:23:13 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
Message-ID: <rhVpqC6kqvLnDYpkcAi7aVFc7e9MIZHN8KhWQ58qc6Y=.7c8d7e36-d1b5-4fc6-930a-39a52641d2db@github.com>

On Tue, 25 Mar 2025 17:59:41 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
>> 
>> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
>> 
>> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 514:
> 
>> 512:              */
>> 513: 
>> 514:             double labelPrefWidth = TitledPaneSkin.super.computePrefWidth(height, 0, 0, 0, 0);
> 
> On a related subject: trying to get the title label truncated (using the code sample in the ticket) did not succeed even though the TitledPane is a Labeled:
> 
> 
>         TitledPane tp1 = new TitledPane("Left Aligned Title with a long long title with ellipses set", ...);
>         tp1.setPrefWidth(100);
>         tp1.setMaxWidth(100);
>         tp1.setEllipsisString("...");
> 
> 
> This seems like a possible bug to me.  What do you think?

created https://bugs.openjdk.org/browse/JDK-8352991

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2014856478

From jhendrikx at openjdk.org  Wed Mar 26 20:04:17 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 26 Mar 2025 20:04:17 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
Message-ID: <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>

On Tue, 25 Mar 2025 17:08:02 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
>> 
>> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
>> 
>> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 160:
> 
>> 158:         registerChangeListener(titleRegion.alignmentProperty(), e -> pos = titleRegion.getAlignment());
>> 159: 
>> 160:         // NOTE: Listening to two different alignment properties, and using the last value of either is likely a bug!
> 
> I agree: it is definitely a bug.  I think we should remove it along with the possibility of specifying conflicting alignment via CSS.  The control must be in control.

Yeah, the reason I was hesitant to change this is that currently you can set the alignment from CSS in two ways:

     .titled-pane {
         -fx-alignment: RIGHT;
     }
     
Or:
 
    .titled-pane > .title {
         -fx-alignment: RIGHT;
    }     
    
Both will work at the moment.  I'm not sure which one is more correct.  

A titled pane naturally has two major regions; its title area, and its content area.  The top level alignment could apply to either or none in theory.  The top level alignment setting is "inherited" from being a Labeled control, which only has a single alignment to worry about (this also shows using this kind of inheritance is just a bad idea).  It would have been much more clear to have a `titleAlignment` and `contentAlignment` property.

At the "top" level there is nothing to align, since a titled pane always fill its width.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2014914945

From jhendrikx at openjdk.org  Wed Mar 26 20:04:19 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 26 Mar 2025 20:04:19 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <rhVpqC6kqvLnDYpkcAi7aVFc7e9MIZHN8KhWQ58qc6Y=.7c8d7e36-d1b5-4fc6-930a-39a52641d2db@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <rhVpqC6kqvLnDYpkcAi7aVFc7e9MIZHN8KhWQ58qc6Y=.7c8d7e36-d1b5-4fc6-930a-39a52641d2db@github.com>
Message-ID: <Gvv9_NkgUn2PT8BZrRHMQoVCAHQ1ahAWtLkprX2q2Wg=.1d6d1c57-36fe-4ccc-a530-592b2528c42f@github.com>

On Wed, 26 Mar 2025 19:20:54 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 514:
>> 
>>> 512:              */
>>> 513: 
>>> 514:             double labelPrefWidth = TitledPaneSkin.super.computePrefWidth(height, 0, 0, 0, 0);
>> 
>> On a related subject: trying to get the title label truncated (using the code sample in the ticket) did not succeed even though the TitledPane is a Labeled:
>> 
>> 
>>         TitledPane tp1 = new TitledPane("Left Aligned Title with a long long title with ellipses set", ...);
>>         tp1.setPrefWidth(100);
>>         tp1.setMaxWidth(100);
>>         tp1.setEllipsisString("...");
>> 
>> 
>> This seems like a possible bug to me.  What do you think?
>
> created https://bugs.openjdk.org/browse/JDK-8352991

Yeah, this problem likely stems from the substructure of the titled pane.  It has a content and title area, but no `VBox` wrapper around those that will do correct calculations. The calculations are just done manually, and they completely ignore many nuances of the layout system.

If `TitledPane` had been based on `VBox` it might have been easier to get correct.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2014918983

From angorya at openjdk.org  Wed Mar 26 20:16:21 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 20:16:21 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
Message-ID: <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>

On Wed, 26 Mar 2025 19:57:59 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 160:
>> 
>>> 158:         registerChangeListener(titleRegion.alignmentProperty(), e -> pos = titleRegion.getAlignment());
>>> 159: 
>>> 160:         // NOTE: Listening to two different alignment properties, and using the last value of either is likely a bug!
>> 
>> I agree: it is definitely a bug.  I think we should remove it along with the possibility of specifying conflicting alignment via CSS.  The control must be in control.
>
> Yeah, the reason I was hesitant to change this is that currently you can set the alignment from CSS in two ways:
> 
>      .titled-pane {
>          -fx-alignment: RIGHT;
>      }
>      
> Or:
>  
>     .titled-pane > .title {
>          -fx-alignment: RIGHT;
>     }     
>     
> Both will work at the moment.  I'm not sure which one is more correct.  
> 
> A titled pane naturally has two major regions; its title area, and its content area.  The top level alignment could apply to either or none in theory.  The top level alignment setting is "inherited" from being a Labeled control, which only has a single alignment to worry about (this also shows using this kind of inheritance is just a bad idea).  It would have been much more clear to have a `titleAlignment` and `contentAlignment` property.
> 
> At the "top" level there is nothing to align, since a titled pane always fill its width.

the original code had some logic around `(pos == null)`, I wonder if we need to do the same here, that is, derive the effective alignment from both values?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2014933886

From oschmidtmer at openjdk.org  Wed Mar 26 20:20:36 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Wed, 26 Mar 2025 20:20:36 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v7]
In-Reply-To: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
Message-ID: <_RYIqjzt0brJVoSliQ6wp55WTaGXq5hePcW_IzuvIRA=.dab9fe0f-4141-4843-ade9-860f90cd7b4e@github.com>

> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
> 
> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  readding flavors with changed mapping

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1724/files
  - new: https://git.openjdk.org/jfx/pull/1724/files/c91ab3b2..7330b8da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=05-06

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1724.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724

PR: https://git.openjdk.org/jfx/pull/1724

From angorya at openjdk.org  Wed Mar 26 20:40:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 20:40:22 GMT
Subject: RFR: 8351878: RichTextArea: copy/paste issues [v5]
In-Reply-To: <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
References: <93nKaMY8XJ2MLqKbXUyctuWqDGr3u4ykYYdnDow8ibM=.942e24ee-1dbd-4eeb-a2fb-a5beff684d3d@github.com>
 <rs-4MqFkEhQm4iyoaZ4u8Ru61Da5gKYfNaUn18ON2L0=.e2d34b26-392f-411b-aaa0-6d6e5dcb8da6@github.com>
Message-ID: <Jm43-zzpuA-W2peElTeknJ8BF3GkLOamTUuO0aQ7fH8=.d39d8e97-ff99-4d4a-b415-7a04dc249a30@github.com>

On Wed, 26 Mar 2025 14:36:39 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Fixed several issues found in importing RTF text:
>> 
>> - charset translation (brought back removed code)
>> - missing font size attribute
>> - missing strike-through attribute
>> 
>> Also, HTML copy suffered from the following issues:
>> 
>> - incorrect font size
>> - incorrect handling of boolean character attributes (bold, italic, etc.)
>> 
>> The charset issue was caused by my removal of the character decoder code present in the original JDK RTF parser/reader.  Why did I do that?
>> 
>> This PR does not add import of RTL paragraph attribute needed to align RTL text correctly.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - html
>  - Merge remote-tracking branch 'origin/master' into 8351878.rtf
>  - arabic
>  - whitespace
>  - test
>  - strikethrough
>  - missing code in attr set
>  - font size
>  - fixed arabic import

Created https://bugs.openjdk.org/browse/JDK-8353003 for the diacritic marks issue.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1735#issuecomment-2755694506

From jhendrikx at openjdk.org  Wed Mar 26 21:39:16 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 26 Mar 2025 21:39:16 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
 <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>
Message-ID: <2D8AESOO5ZU5qZqd54AeqslaONKZ5l6sy8bppg9W6oU=.7173a0a9-6149-4a94-b376-110b85a17a21@github.com>

On Wed, 26 Mar 2025 20:13:25 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Yeah, the reason I was hesitant to change this is that currently you can set the alignment from CSS in two ways:
>> 
>>      .titled-pane {
>>          -fx-alignment: RIGHT;
>>      }
>>      
>> Or:
>>  
>>     .titled-pane > .title {
>>          -fx-alignment: RIGHT;
>>     }     
>>     
>> Both will work at the moment.  I'm not sure which one is more correct.  
>> 
>> A titled pane naturally has two major regions; its title area, and its content area.  The top level alignment could apply to either or none in theory.  The top level alignment setting is "inherited" from being a Labeled control, which only has a single alignment to worry about (this also shows using this kind of inheritance is just a bad idea).  It would have been much more clear to have a `titleAlignment` and `contentAlignment` property.
>> 
>> At the "top" level there is nothing to align, since a titled pane always fill its width.
>
> the original code had some logic around `(pos == null)`, I wonder if we need to do the same here, that is, derive the effective alignment from both values?

That was just for deriving the `hpos` and `vpos` fields, which are no longer needed, in case `pos` was `null`.  The `null` check is now handled in `LabeledSkinBase`.

Of course we could think of some kind of derive option (how to derive LEFT + RIGHT?) or a way to remove one of these, but I think either way, it's outside the scope of this change.  I added the comment for future maintainers (I could have left it out, and we'd probably not be having this discussion).  

As it is, I don't think we should fix this as part of this change as it is really completely unrelated (and might need much more discussion and perhaps even a CSR...)

Perhaps I should remove the comment and instead we describe this in an issue?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2015031232

From angorya at openjdk.org  Wed Mar 26 21:51:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 21:51:10 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <2D8AESOO5ZU5qZqd54AeqslaONKZ5l6sy8bppg9W6oU=.7173a0a9-6149-4a94-b376-110b85a17a21@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
 <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>
 <2D8AESOO5ZU5qZqd54AeqslaONKZ5l6sy8bppg9W6oU=.7173a0a9-6149-4a94-b376-110b85a17a21@github.com>
Message-ID: <1TFdcS-eoYUnbt6u0wQgIObc32IBb9HXP3Px23pk2KI=.bebc4cb6-34cf-4048-9635-39b72707f779@github.com>

On Wed, 26 Mar 2025 21:36:22 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> the original code had some logic around `(pos == null)`, I wonder if we need to do the same here, that is, derive the effective alignment from both values?
>
> That was just for deriving the `hpos` and `vpos` fields, which are no longer needed, in case `pos` was `null`.  The `null` check is now handled in `LabeledSkinBase`.
> 
> Of course we could think of some kind of derive option (how to derive LEFT + RIGHT?) or a way to remove one of these, but I think either way, it's outside the scope of this change.  I added the comment for future maintainers (I could have left it out, and we'd probably not be having this discussion).  
> 
> As it is, I don't think we should fix this as part of this change as it is really completely unrelated (and might need much more discussion and perhaps even a CSR...)
> 
> Perhaps I should remove the comment and instead we describe this in an issue?

I agree: this change is out of scope for this PR.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2015044999

From angorya at openjdk.org  Wed Mar 26 22:35:16 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Wed, 26 Mar 2025 22:35:16 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
Message-ID: <c8ZHpLHBDmZuqQeIAdNUWtwoaf3ouUWn9neUUaVM8g0=.14c95100-065f-4921-8be5-224b4a9d4f93@github.com>

On Sat, 22 Mar 2025 12:20:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
> 
> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
> 
> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

lgtm

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1742#pullrequestreview-2718749341

From crschnick at xpipe.io  Thu Mar 27 04:20:15 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Thu, 27 Mar 2025 05:20:15 +0100
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
 <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
Message-ID: <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>

Interesting, that exception does not happen on my macOS 15.3 system. The 
reproducer somehow also doesn't seem to trigger the 
IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. On 
Windows, the large alert is shown as a broken stage with no content and 
controls for me, which I guess is slightly better than an exception, but 
also not ideal.? So it seems like the reproducer behavior depends a lot 
on the specific system.

On 26/03/2025 19:35, Martin Fox wrote:
> Christopher,
>
> Yes, there might be more than one issue here. On the Mac the call to 
> Stage.showAndWait is making its way into the Mac glass code where an 
> exception is being thrown leading to another call to 
> Stage.showAndWait. I?ve attached the repeating block below. I don?t 
> see that pattern in the Windows stack trace you provided.
>
> Martin
>
> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
> at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
> at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
> at 
> javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException(Application.java:452)
> at 
> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2(Native 
> Method)
> at 
> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds(MacWindow.java:70)
> at 
> javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds(Window.java:589)
> at 
> javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds(WindowStage.java:304)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply(Window.java:1566)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window.applyBounds(Window.java:1424)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window.adjustSize(Window.java:327)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene(Window.java:284)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated(Window.java:1215)
> at 
> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
> at 
> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
> at 
> javafx.graphics at 25-internal/javafx.stage.Window.setShowing(Window.java:1235)
> at javafx.graphics at 25-internal/javafx.stage.Window.show(Window.java:1250)
> at javafx.graphics at 25-internal/javafx.stage.Stage.show(Stage.java:272)
> at 
> javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Stage.java:427)
> at 
> javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(HeavyweightDialog.java:162)
> at 
> javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Dialog.java:347)
> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
> at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
> at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>
>> On Mar 26, 2025, at 10:49?AM, Christopher Schnick 
>> <crschnick at xpipe.io> wrote:
>>
>> Hey Martin,
>>
>> thank you for looking into this. The initial StackOverflow is a 
>> result of me forcing to reproduce the bounds 
>> IndexOutOfBoundsException. The StackOverflow can be ignored, it was 
>> merely the best method I found to transition the scene graph into a 
>> state where the IndexOutOfBoundsExceptions are thrown. The OOBs are 
>> not thrown in every run though, it sometimes takes a few tries. In 
>> our production application, the same IndexOutOfBoundsExceptions also 
>> occur randomly without a previous exception. You can probably also 
>> reproduce the IndexOutOfBoundsExceptions without the StackOverflow, 
>> but reproducing it was very fragile, so I didn't look into it more.
>>
>> I don't think it has necessarily something to do with the alert 
>> bounds as the IndexOutOfBoundsException is also thrown if you don't 
>> show an alert at all. The constant IndexOutOfBoundsExceptions in 
>> combination with the alert showAndWait was how our application 
>> entered the original crashing state. So the reproducer is more like a 
>> two-in-one.
>>
>> Best
>> Christopher Schnick
>>
>> On 26/03/2025 18:33, Martin Fox wrote:
>>> Yes, thank you Christopher for providing a reproducible test case!
>>>
>>> I was able to trigger the problem on my Mac on the first try. Since 
>>> I?m using a modified version of JavaFX the system didn?t crash but 
>>> instead hit a Java stack overflow error and produced a very long 
>>> stack trace.
>>>
>>> At least on the Mac the problem seems to be that you?re trying to 
>>> pop an Alert containing a long stack trace. While trying to adjust 
>>> the Alert?s bounds JavaFX is throwing another exception but I?m not 
>>> sure why. I?ll continue to look into it.
>>>
>>> Thanks again,
>>> Martin
>>>
>>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev 
>>>> <andy.goryachev at oracle.com> wrote:
>>>>
>>>> Thank you, Christopher, for clarification!
>>>> Personally, I would consider this to be a problem with the 
>>>> application design: the code should limit the number of alerts 
>>>> shown to the user.? Do you really want the user to click through 
>>>> hundreds of alerts?
>>>> Nevertheless, you are right about the need for the platform to 
>>>> gracefully handle the case of too many nested event loops - by 
>>>> throwing an exception with a meaningful message, as Martin proposed 
>>>> inhttps://github.com/openjdk/jfx/pull/1741
>>>> Cheers,
>>>> -andy
>>>>
>>>> *From:*Christopher Schnick <crschnick at xpipe.io>
>>>> *Date:*Tuesday, March 25, 2025 at 11:52
>>>> *To:*Andy Goryachev <andy.goryachev at oracle.com>
>>>> *Cc:*OpenJFX <openjfx-dev at openjdk.org>
>>>> *Subject:*Re: [External] : Re: JVM crashes on macOS when entering 
>>>> too many nested event loops
>>>>
>>>> Hey Andy,
>>>>
>>>> so I think I was able to reproduce this issue for our application.
>>>>
>>>> There are two main factors how this can happen:
>>>> - We use an alert-based error reporter, meaning that we have a 
>>>> default uncaught exception handler set for all threads which will 
>>>> showAndWait an Alert with the exception message
>>>> - As I reported yesterday 
>>>> withhttps://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, 
>>>> there are some rare exceptions that can occur in a normal event 
>>>> loop without interference of the application, probably because of a 
>>>> small bug in the bounds calculation code
>>>>
>>>> If you combine these two factors, you will end up with an infinite 
>>>> loop of the showAndWait entering a nested event loop, the event 
>>>> loop throwing an internal exception, and the uncaught exception 
>>>> handler starting the same loop with another alert. I don't think 
>>>> this is a bad implementation from our side, the only thing that we 
>>>> can improve is to maybe check how deep the uncaught exception loop 
>>>> is in to prevent this from occurring indefinitely. But I would 
>>>> argue this can happen to any application. Here is a sample code, 
>>>> based on the reproducer from the OutOfBounds report from yesterday:
>>>>
>>>> import javafx.application.Application;
>>>> import javafx.application.Platform;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.Alert;
>>>> import javafx.scene.control.Button;
>>>> import javafx.scene.layout.Region;
>>>> import javafx.scene.layout.StackPane;
>>>> import javafx.scene.layout.VBox;
>>>> import javafx.stage.Stage;
>>>> import java.io.IOException;
>>>> import java.util.Arrays;
>>>> public class ParentBoundsBug extends Application {
>>>> @Override
>>>> public void start(Stage stage) throws IOException {
>>>> ??????? Thread./setDefaultUncaughtExceptionHandler/((thread, 
>>>> throwable) -> {
>>>> ??????????? throwable.printStackTrace();
>>>> if (Platform./isFxApplicationThread/()) {
>>>> var alert = new Alert(Alert.AlertType./ERROR/);
>>>> ??????????????? alert.setHeaderText(throwable.getMessage());
>>>> ??????????????? 
>>>> alert.setContentText(Arrays./toString/(throwable.getStackTrace()));
>>>> ??????????????? alert.showAndWait();
>>>> ??????????? } else {
>>>> // Do some other error handling for non-platform threads
>>>> ??????????????? // Probably just show the alert with a runLater()
>>>> ??????????????? // For this example, there are no exceptions 
>>>> outside the platform thread
>>>> }
>>>> ??????? });
>>>> // Run delayed as Application::reportException will only be called 
>>>> for exceptions
>>>> ??????? // after the application has started
>>>> Platform./runLater/(() -> {
>>>> ??????????? Scene scene = new Scene(createContent(), 640, 480);
>>>> stage.setScene(scene);
>>>> stage.show();
>>>> stage.centerOnScreen();
>>>> ??????? });
>>>> ??? }
>>>> private Region createContent() {
>>>> var b1 = new Button("Click me!");
>>>> var b2 = new Button("Click me!");
>>>> var vbox = new VBox(b1, b2);
>>>> ??????? b1.boundsInParentProperty().addListener((observable, 
>>>> oldValue, newValue) -> {
>>>> vbox.setVisible(!vbox.isVisible());
>>>> ??????? });
>>>> ??????? b2.boundsInParentProperty().addListener((observable, 
>>>> oldValue, newValue) -> {
>>>> vbox.setVisible(!vbox.isVisible());
>>>> ??????? });
>>>> ??????? vbox.boundsInParentProperty().addListener((observable, 
>>>> oldValue, newValue) -> {
>>>> vbox.setVisible(!vbox.isVisible());
>>>> ??????? });
>>>> var stack = new StackPane(vbox, new StackPane());
>>>> ??????? stack.boundsInParentProperty().addListener((observable, 
>>>> oldValue, newValue) -> {
>>>> vbox.setVisible(!vbox.isVisible());
>>>> ??????? });
>>>> return stack;
>>>> ??? }
>>>> public static void main(String[] args) {
>>>> /launch/();
>>>> ??? }
>>>> }
>>>>
>>>>
>>>> If the same OutOfBounds exception from the reported I linked 
>>>> happens in the bounds calculation, which happens approximately 1/5 
>>>> runs for me, this application will enter new event loops until it 
>>>> crashes. If the OutOfBounds doesn't trigger, it will just throw a 
>>>> StackOverflow but won't continue the infinite loop of nested event 
>>>> loops. So for the reproducer it is important to try a few times 
>>>> until you get the described OutOfBounds.
>>>>
>>>> I attached the stacktrace of how this fails. The initial 
>>>> StackOverflow causes infinitely many following exceptions in the 
>>>> nested event loop.
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>>>
>>>>     Dear Christopher:
>>>>     Were you able to root cause why your application enters that
>>>>     many nested event loops?
>>>>     I believe a well-behaved application should never experience
>>>>     that, unless there is some design flaw or a bug.
>>>>     -andy
>>>>
>>>>     *From:*Christopher Schnick<crschnick at xpipe.io>
>>>>     <mailto:crschnick at xpipe.io>
>>>>     *Date:*Monday, March 10, 2025 at 19:45
>>>>     *To:*Andy Goryachev<andy.goryachev at oracle.com>
>>>>     <mailto:andy.goryachev at oracle.com>
>>>>     *Subject:*[External] : Re: JVM crashes on macOS when entering
>>>>     too many nested event loops
>>>>
>>>>     Our code and some libraries do enter some nested event loops at
>>>>     a few places when it makes sense, but we didn't do anything to
>>>>     explicitly provoke this, this occurred naturally in our
>>>>     application. So it would be nice if JavaFX could somehow guard
>>>>     against this, especially since crashing the JVM is probably the
>>>>     worst thing that can happen.
>>>>
>>>>     I looked at the documentation, but it seems like the public API
>>>>     at Platform::enterNestedEventLoop does not mention this.
>>>>     From my understanding, the method
>>>>     Platform::canStartNestedEventLoop is potentially the right
>>>>     method to indicate to the caller that the limit is close by
>>>>     returning false.
>>>>     And even if something like an exception is thrown when a nested
>>>>     event loop is started while it is close to the limit, that
>>>>     would still be much better than a direct crash.
>>>>
>>>>     Best
>>>>     Christopher Schnick
>>>>
>>>>     On 10/03/2025 18:51, Andy Goryachev wrote:
>>>>
>>>>         This looks to me like it might be hitting the (native)
>>>>         thread stack size limit.
>>>>         c.s.glass.ui.Application::enterNestedEventLoop() even warns
>>>>         about it:
>>>>         * An application may enter several nested loops
>>>>         recursively. There's no
>>>>         * limit of recursion other than that imposed by the native
>>>>         stack size.
>>>>         -andy
>>>>
>>>>         *From:*openjfx-dev<openjfx-dev-retn at openjdk.org>
>>>>         <mailto:openjfx-dev-retn at openjdk.org>on behalf of Martin
>>>>         Fox<martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>>>         *Date:*Monday, March 10, 2025 at 10:10
>>>>         *To:*Christopher Schnick<crschnick at xpipe.io>
>>>>         <mailto:crschnick at xpipe.io>
>>>>         *Cc:*OpenJFX<openjfx-dev at openjdk.org>
>>>>         <mailto:openjfx-dev at openjdk.org>
>>>>         *Subject:*Re: JVM crashes on macOS when entering too many
>>>>         nested event loops
>>>>
>>>>         Hi Christopher,
>>>>
>>>>         I was able to reproduce this crash. I wrote a small routine
>>>>         that recursively calls itself in a runLater block and then
>>>>         enters a nested event loop. The program crashes when
>>>>         creating loop 254. I?m not sure where that limit comes from
>>>>         so it?s possible that consuming some other system resource
>>>>         could lower it. I couldn?t see any good way to determine
>>>>         how many loops are active by looking at the crash report
>>>>         since it doesn?t show the entire call stack.
>>>>         I did a quick trial on Linux and was able to create a lot
>>>>         more loops (over 600) but then started seeing erratic
>>>>         behavior and errors coming from the Java VM. The behavior
>>>>         was variable unlike on the Mac which always crashes when
>>>>         creating loop 254.
>>>>
>>>>         Martin
>>>>
>>>>         > On Mar 7, 2025, at 6:24?AM, Christopher
>>>>         Schnick<crschnick at xpipe.io> <mailto:crschnick at xpipe.io>wrote:
>>>>         >
>>>>         > Hello,
>>>>         >
>>>>         > I have attached a JVM fatal error log that seemingly was
>>>>         caused by our JavaFX application entering too many nested
>>>>         event loops, which macOS apparently doesn't like.
>>>>         >
>>>>         > As far as I know, there is no upper limit defined on how
>>>>         often an event loop can be nested, so I think this is a bug
>>>>         that can occur in rare situations.
>>>>         >
>>>>         > Best
>>>>         > Christopher Schnick<hs_err_pid.txt>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250327/f095a7ba/attachment-0001.htm>

From lkostyra at openjdk.org  Thu Mar 27 10:19:23 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Thu, 27 Mar 2025 10:19:23 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v7]
In-Reply-To: <_RYIqjzt0brJVoSliQ6wp55WTaGXq5hePcW_IzuvIRA=.dab9fe0f-4141-4843-ade9-860f90cd7b4e@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <_RYIqjzt0brJVoSliQ6wp55WTaGXq5hePcW_IzuvIRA=.dab9fe0f-4141-4843-ade9-860f90cd7b4e@github.com>
Message-ID: <Gx57z0w_0Xt9ZYdCzNLzeQfxaK-6hzyUqky__mdNdQI=.bbceee45-b9c6-4ac1-9b5e-33dbce7535bb@github.com>

On Wed, 26 Mar 2025 20:20:36 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   readding flavors with changed mapping

Changes requested by lkostyra (Reviewer).

modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 207:

> 205: {
> 206:     addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
> 207:     addPair(GLASS_TEXT_PLAIN_LOCALE, CF_UNICODETEXT);

Seems like those changes made JFX unaware of text data ready to be pasted from "outside" - running your test program and trying to paste something to a TextBox (ex. in `HelloTextBoxClipboard`) doesn't work anymore (Paste popup menu option is disabled, Ctrl+V does nothing, whereas both were possible to do on master). I checked that these mime stuff changes are at fault.

My guess now would be that these mime_stuff changes have to be reverted and the actual change should happen as we request Clipboard data - probably a condition changing clipboard format `cf` from `CF_TEXT` and `CF_OEMTEXT` to `CF_UNICODETEXT` right before we call `me.Load()` in `PopMemory()`. Please check if that is in fact the case before committing though, I'm not 100% sure if that would work.

If that works, a comment explaining why we do this clipboard format swap would also come in handy for future generations.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2720659536
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2016138135

From ambarish.rapte at oracle.com  Thu Mar 27 12:33:56 2025
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Thu, 27 Mar 2025 12:33:56 +0000
Subject: JavaFX Metal: Second EA build available for Testing
Message-ID: <PH7PR10MB78500F3872F18EE727D93EEFF0A12@PH7PR10MB7850.namprd10.prod.outlook.com>

Hello,



 The second Early Access(EA) build of JavaFX with the macOS Metal rendering pipeline is now available at: https://jdk.java.net/javafxmetal



 An important change in this release is that the ES2 and SW pipeline are now available for selection, though metal remains the default pipeline.

  In addition to metal pipeline, we request to sanity test the other pipelines as well i.e. -Dprism.order=es2 and -Dprism.order=sw

 The list of bugs fixed in EA2 can be found here: https://bugs.openjdk.org/issues/?filter=47143.



  Please test this build and share your feedback by:

  - Emailing openjfx-dev at openjdk.java.net<mailto:openjfx-dev at openjdk.java.net> or

  - Reporting issues via JBS[https://bugs.openjdk.org/] or at https://bugreport.java.com<https://bugreport.java.com/>



 For more details, please refer to the EA1 email.



  We look forward to your feedback.



Regards,

Ambarish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250327/92c902b9/attachment.htm>

From oschmidtmer at openjdk.org  Thu Mar 27 13:17:29 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Thu, 27 Mar 2025 13:17:29 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v7]
In-Reply-To: <Gx57z0w_0Xt9ZYdCzNLzeQfxaK-6hzyUqky__mdNdQI=.bbceee45-b9c6-4ac1-9b5e-33dbce7535bb@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <_RYIqjzt0brJVoSliQ6wp55WTaGXq5hePcW_IzuvIRA=.dab9fe0f-4141-4843-ade9-860f90cd7b4e@github.com>
 <Gx57z0w_0Xt9ZYdCzNLzeQfxaK-6hzyUqky__mdNdQI=.bbceee45-b9c6-4ac1-9b5e-33dbce7535bb@github.com>
Message-ID: <Jaoe_JBj_cdjv_3HdA2Znp_MEvqRqDaaFRnfiLfAejE=.ef17ef46-fc13-458d-ae0e-ea9b820118fa@github.com>

On Thu, 27 Mar 2025 10:06:02 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

>> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   readding flavors with changed mapping
>
> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 207:
> 
>> 205: {
>> 206:     addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
>> 207:     addPair(GLASS_TEXT_PLAIN_LOCALE, CF_UNICODETEXT);
> 
> Seems like those changes made JFX unaware of text data ready to be pasted from "outside" - running your test program and trying to paste something to a TextBox (ex. in `HelloTextBoxClipboard`) doesn't work anymore (Paste popup menu option is disabled, Ctrl+V does nothing, whereas both were possible to do on master). I checked that these mime stuff changes are at fault.
> 
> My guess now would be that these mime_stuff changes have to be reverted and the actual change should happen as we request Clipboard data - probably a condition changing clipboard format `cf` from `CF_TEXT` and `CF_OEMTEXT` to `CF_UNICODETEXT` right before we call `me.Load()` in `PopMemory()`. Please check if that is in fact the case before committing though, I'm not 100% sure if that would work.
> 
> If that works, a comment explaining why we do this clipboard format swap would also come in handy for future generations.

I can't check if replacing cf with CF_UNICODETEXT there works, as probably that flavor is already always prioritized.

My test for the early NUL terminator explicitly only sets CF_TEXT, but is converted to unicode.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2016556715

From angorya at openjdk.org  Thu Mar 27 14:24:28 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 27 Mar 2025 14:24:28 GMT
Subject: RFR: 8347359: RichTextArea API Tests [v5]
In-Reply-To: <djPPtfzJbhsufwKoYdH5ESH6kZ0vjMA9ODT2Z-vXwvM=.26696603-f5f9-4ca4-9872-418495830bc4@github.com>
References: <co1iKN4U1AsgxNWruddZsTBMR8TwgA-IBLbpa4WauuQ=.f6903595-60e5-4b17-9bb2-09fc227eb2cb@github.com>
 <djPPtfzJbhsufwKoYdH5ESH6kZ0vjMA9ODT2Z-vXwvM=.26696603-f5f9-4ca4-9872-418495830bc4@github.com>
Message-ID: <dvqrq6rEgMLT9b_snfzxW28oUt8ZIQi3-e0j_ndUbt4=.a33ccdf4-3162-412c-932b-0e82e98db57c@github.com>

On Wed, 26 Mar 2025 14:46:07 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Additional RichTextArea API tests.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - Merge remote-tracking branch 'origin/master' into 8347359.rta.api.tests
>  - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into 8347359.rta.api.tests
>  - review comments
>  - Merge remote-tracking branch 'origin/8348736.rta.followup.2' into
>    8347359.rta.api.tests
>  - newlines
>  - check
>  - ... and 13 more: https://git.openjdk.org/jfx/compare/91433775...c0cde4a9

@arapte or @Ziad-Mid please review

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1677#issuecomment-2758240096

From mfox at openjdk.org  Thu Mar 27 15:21:09 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 27 Mar 2025 15:21:09 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v5]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with two additional commits since the last revision:

 - Removed unnecessary import
 - The max nested event loop constant is no longer public

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/b08594fe..3ae07ff9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=04
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=03-04

  Stats: 17 lines in 4 files changed: 5 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From angorya at openjdk.org  Thu Mar 27 17:06:19 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 27 Mar 2025 17:06:19 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v5]
In-Reply-To: <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
Message-ID: <FJbMHBARp7mEhjcVfrnCqFj4dWMZei-UXHltnB-45ec=.574e69a2-abab-46cd-bb59-40322b81a01b@github.com>

On Thu, 27 Mar 2025 15:21:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed unnecessary import
>  - The max nested event loop constant is no longer public

Looks good!  The exception message should be clear enough for a developer who is encountering it for the first time.

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2722705090

From kcr at openjdk.org  Thu Mar 27 17:20:42 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 27 Mar 2025 17:20:42 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v5]
In-Reply-To: <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
Message-ID: <RNVWS0-ts2eI6V4-UaXezZQWUhH1D--LdxPP5ULQBhg=.8126ebea-9be1-4346-99a0-da75b73c8010@github.com>

On Thu, 27 Mar 2025 15:21:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed unnecessary import
>  - The max nested event loop constant is no longer public

This needs a second reviewer. It will likely need a CSR since there is a new exception being documented and throws.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2758851795

From kcr at openjdk.org  Thu Mar 27 17:47:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 27 Mar 2025 17:47:17 GMT
Subject: RFR: 8351733: [macos] Crash when creating too many nested event
 loops [v5]
In-Reply-To: <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
Message-ID: <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>

On Thu, 27 Mar 2025 15:21:09 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removed unnecessary import
>  - The max nested event loop constant is no longer public

The implementation looks good.

I left one question / suggestion on the type of Exception throws.

I think the suggestion made by @mstr2 to recommend calling `canStartNestedLoop` if the app wants to know whether or not this call will succeed is a good one.

I think we should update the docs for `Stage::showAndWait` documenting the same exception, since the implementation of that method also spins up a nested event loop.

Since this fix has been expanded to all platforms, let's remove `[macos]` from the title of the JBS issue and PR.

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 305:

> 303:      * other than the JavaFX Application Thread.
> 304:      *
> 305:      * @throws RuntimeException if this call would exceed the maximum

I wonder if there is a more specific subclass of `RuntimeException` that we could throw? Maybe `IllegalStateException`, which seems the closest in meaning and has the advantage that we already throw it in other cases.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2722832212
PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2758937412
PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2017254207

From mfox at openjdk.org  Thu Mar 27 19:42:21 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 27 Mar 2025 19:42:21 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v5]
In-Reply-To: <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
 <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>
Message-ID: <xL1an5ioJD74HaPZy36Ve7ZiU4IoMdvrbZ7m12XRJjs=.237d5802-bacc-4d2c-9180-dfab887fd29e@github.com>

On Thu, 27 Mar 2025 17:33:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Removed unnecessary import
>>  - The max nested event loop constant is no longer public
>
> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 305:
> 
>> 303:      * other than the JavaFX Application Thread.
>> 304:      *
>> 305:      * @throws RuntimeException if this call would exceed the maximum
> 
> I wonder if there is a more specific subclass of `RuntimeException` that we could throw? Maybe `IllegalStateException`, which seems the closest in meaning and has the advantage that we already throw it in other cases.

I'll have to wait for others to chime in on that question, I don't have much background in this area.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2017499898

From angorya at openjdk.org  Thu Mar 27 19:47:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 27 Mar 2025 19:47:22 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v5]
In-Reply-To: <xL1an5ioJD74HaPZy36Ve7ZiU4IoMdvrbZ7m12XRJjs=.237d5802-bacc-4d2c-9180-dfab887fd29e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
 <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>
 <xL1an5ioJD74HaPZy36Ve7ZiU4IoMdvrbZ7m12XRJjs=.237d5802-bacc-4d2c-9180-dfab887fd29e@github.com>
Message-ID: <oR93qHKoSEnwA3pJYOUFkYRUPyVSK35vY5gqPanX23w=.79918f86-a54f-461c-bfe3-f9821b394df2@github.com>

On Thu, 27 Mar 2025 19:39:23 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 305:
>> 
>>> 303:      * other than the JavaFX Application Thread.
>>> 304:      *
>>> 305:      * @throws RuntimeException if this call would exceed the maximum
>> 
>> I wonder if there is a more specific subclass of `RuntimeException` that we could throw? Maybe `IllegalStateException`, which seems the closest in meaning and has the advantage that we already throw it in other cases.
>
> I'll have to wait for others to chime in on that question, I don't have much background in this area.

The `IllegalStateException` is the right one, as it states that it _"Signals that a method has been invoked at an illegal or inappropriate time."_

Another positive thing it will probably eliminate the need for a CSR as this method already throws one.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2017506290

From mfox at openjdk.org  Thu Mar 27 21:59:52 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 27 Mar 2025 21:59:52 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v6]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <bNISfD4EOAuyTP6RB3joF2E6_N6fauYKH9oSRMyeW2U=.b02cbc58-ca6f-4c20-ad2e-a72a8541276f@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Now throwing an IllegalStateException

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/3ae07ff9..99d2878f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=05
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=04-05

  Stats: 5 lines in 4 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From angorya at openjdk.org  Thu Mar 27 22:13:49 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 27 Mar 2025 22:13:49 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v6]
In-Reply-To: <bNISfD4EOAuyTP6RB3joF2E6_N6fauYKH9oSRMyeW2U=.b02cbc58-ca6f-4c20-ad2e-a72a8541276f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <bNISfD4EOAuyTP6RB3joF2E6_N6fauYKH9oSRMyeW2U=.b02cbc58-ca6f-4c20-ad2e-a72a8541276f@github.com>
Message-ID: <pIv48Hs-grSHPxryhqs2M8t9Xr_fVpJs6i40wncpHJs=.665bb071-8274-46d0-b050-b5b8f6d1e812@github.com>

On Thu, 27 Mar 2025 21:59:52 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Now throwing an IllegalStateException

Do we still need a CSR @kevinrushforth ?

-------------

Marked as reviewed by angorya (Reviewer).

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2723479174

From mfox at openjdk.org  Thu Mar 27 22:22:23 2025
From: mfox at openjdk.org (Martin Fox)
Date: Thu, 27 Mar 2025 22:22:23 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v3]
In-Reply-To: <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>
Message-ID: <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>

On Wed, 26 Mar 2025 08:34:06 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lower limit on run loop nesting
>
> In any case, this PR should at least add the following bits of information to `Platform.enterNestedEventLoop()`:
> 1. There is some limit to the number of nested event loops.
> 2. Applications should always check `Platform.canStartNestedEventLoop()` before invoking `enterNestedEventLoop()`.
> 3. An exception will be thrown if the limit is exceeded.

> I think the suggestion made by @mstr2 to recommend calling `canStartNestedLoop` if the app wants to know whether or not this call will succeed is a good one.

The docs on `canStartNestedEventLoop` describe its behavior already. I'm not sure what further information would be useful. Would it be enough to add a see also link?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2759650479

From mstrauss at openjdk.org  Fri Mar 28 06:01:28 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 28 Mar 2025 06:01:28 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v3]
In-Reply-To: <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>
 <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>
Message-ID: <1fys35MLDad0FdF52ICk8KtGttyVf2DlLNIaJKP7uPg=.8c7ae286-5b8d-48ea-bc6d-836244576de0@github.com>

On Thu, 27 Mar 2025 22:19:29 GMT, Martin Fox <mfox at openjdk.org> wrote:

> The docs on `canStartNestedEventLoop` describe its behavior already. I'm not sure what further information would be useful. Would it be enough to add a see also link?

The exception being thrown is a behavior of `enterNestedEventLoop()`, and should therefore be documented with this method (`@see` is not enough). While that is done now with the `@throws` javadoc tag, I think it wouldn't hurt to be more explicit about that; much in the same way as the javadoc summary already contains an explicit description of the preconditions of calling the method.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2760287067

From johan.vos at gluonhq.com  Fri Mar 28 07:52:13 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 28 Mar 2025 08:52:13 +0100
Subject: Building OpenJFX with the JDK build system
In-Reply-To: <321bb7c6-ccce-4414-bb6b-3c68d3ed3ec6@oracle.com>
References: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
 <321bb7c6-ccce-4414-bb6b-3c68d3ed3ec6@oracle.com>
Message-ID: <CABxFH2Euznf50exCLxc88vqvYg16mjQzaEzqj7b3zXu+9B6ZMQ@mail.gmail.com>

Hi Phil,

Thanks for your reply. I agree that the webkit build should be very doable,
as it is in fact simply invoking make to an external project.
I am slightly more worried about the generation of the shader code, and the
use of antlr for this. I'd like to use the gensrc phase of the jdk for
this, but I'm a bit stuck on using that with external dependencies.

My main work over the past weeks has been in finding a "balanced" approach
for maintaining the OpenJFX code and the build instructions.
I wrote a second post about this, with a proposal:
https://johanvos.wordpress.com/2025/03/27/building-a-jdk-including-openjfx-part-2/

My first efforts were to check if it would be feasible to build OpenJFX
with the OpenJDK build system, and my focus then shifted to how
maintainable it can be.
For very good reasons, the impact of whatever we do/require in OpenJFX on
the JDK build team/infrastructure should be very minimal. I explored a
number of options, and my current suggested approach is to (for now) keep
the OpenJFX sources in the openjdk/jfx repository, and having the
build/make logic in a skara-synced fork of openjdk/jdk. I added a
`--with-openjfx-modules` option to configure for this.

The TLDR of this is: the OpenJFX code stays in the openjfx repo, and the
configure/make logic goes into an auto-synced jdk-fork.

While this second step has nothing to do with the code, and even the
building itself, I believe it is really important to get it right. Being
able to distribute different versions of JavaFX for different platforms,
making them work with well-defined versions of the JDK is key to the
success and adoption of JavaFX, and it has a considerable influence on the
cost of maintaining (and distributing) JavaFX.

That is why my suggested approach separates the (semantic/repository)
location of code and build logic. It is not enough to use the existing
OpenJDK build logic (including toolchain with matching compiler/lib
versions); we also need to be able to auto-update to changes in this build
logic, versions, compilers, libraries...

I am very much looking forward to opinions about this.

- Johan


On Tue, Mar 11, 2025 at 9:01?PM Philip Race <philip.race at oracle.com> wrote:

> I see no one has responded. That isn't because of a lack of interest ..
> we just haven't had time to discuss it.
>
> Undoubtedly a lot of details to figure out but my take is this is worth
> pursuing.
>
> For webkit, I'd like to think it is *possible* to build it using the JDK
> build system, at least
> used as a bootstrap for the cmake webkit build, and at the end to
> collect the artifacts.
>
> A "clean up compiler warnings" effort would be valuable on its own.
> Until we actually transitioned the build, we'd probably have to add to
> the gradle system
> a way to disable specific warnings, like the JDK does, because it isn't
> practical to eliminate all warnings,
> since they some times come from a 3rd party library.
>
> -phil.
>
>
> On 2/27/25 7:15 AM, Johan Vos wrote:
> > Hi,
> >
> > I introduced this topic during the OpenJDK Committers' workshop in
> > Brussels, on Feb 3, 2025.
> > For a long time, I was thinking about building OpenJFX using the JDK
> > buildsystem, and I just blogged about a very basic and limited POC for
> > doing so on Linux:
> > https://johanvos.wordpress.com/2025/02/27/building-openjfx-using-jdk/
> > . The POC I have for this (linux-only at the moment) is at
> > https://github.com/johanvos/jdk/tree/jfxpoc-blog
> > This is just a personal idea and effort, but I would be more than
> > happy to discuss how we as the OpenJFX developers might benefit from
> this.
> >
> > One of the main reasons for doing this (I list a number of reasons in
> > my blog post), is the cross-compilation capability. It is also very
> > convenient that the result of the build is now a full JDK image,
> > including the JavaFX modules. I am aware that some companies
> > distribute JavaFX modules with their JDK distribution, and this might
> > help a better alignment.
> >
> > Since I am also the OpenJDK/Mobile project lead, I have to work with
> > the JDK build system anyhow. To me personally, it saves a major amount
> > of time if I only have to use 1 build system (configure/make) instead
> > of 2 build systems. This is no criticism at all to Gradle, but I lack
> > the expertise (and time to learn) needed to work efficiently with it.
> > With all the projects I do, I try to be as efficient as possible with
> > my time, and streamlining build systems helps.
> > The JDK build system is really excellent, and since it is used by so
> > many OpenJDK developers, it feels very familiar. The delta that is
> > needed to have it working and support for JavaFX is very small.
> >
> > The POC I did is far from complete. There are a number of issues that
> > need to be tackled, e.g.:
> > * what about webkit?
> > * we have a code-generator for shaders, that is using a very old
> > external dependency. While the JDK build system has great support to
> > generate code, I'm not sure this is the ideal approach
> > * warnings, warnings and warnings.
> >
> > The last item is something that I believe should be tacklked in any
> > case. I had to disable the warnings-as-errors, and I had to add a fair
> > amount of exceptions to javac warnings. This might be a good time to
> > look into this as well.
> >
> > Again, I want to stress that this is just an experiment I did because
> > it would save me lots of time, and make it much easier for me to
> > understand what is going on in builds. I absolutely do not want to
> > imply that this is much better than what we currently have. But maybe
> > others are interested as well, and in that case we can discuss this.
> >
> > - Johan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/a8007bd7/attachment-0001.htm>

From johan.vos at gluonhq.com  Fri Mar 28 07:58:54 2025
From: johan.vos at gluonhq.com (Johan Vos)
Date: Fri, 28 Mar 2025 08:58:54 +0100
Subject: Building OpenJFX with the JDK build system
In-Reply-To: <bddd8b07-e779-4d96-ae6f-82e2199be4bc@status6.com>
References: <CABxFH2GJyDBWqeQrBWb8C8eqkpxpA68dYRE+iORK=chaAfdMcA@mail.gmail.com>
 <bddd8b07-e779-4d96-ae6f-82e2199be4bc@status6.com>
Message-ID: <CABxFH2HoeQ_=hxm5Q2mFFSg9uPMVEBPr2iuE6dV3ZxWVuL-HpA@mail.gmail.com>

Hi John,

Many thanks for the feedback and the confirmation, much appreciated!
As for the question "when can we switch?" -> aha, great question. I believe
the major todo is to make sure that this approach is maintainable, without
putting a burden on the openjkd/jdk development, making sure it does not
make the life of the current openjfx developers/reviewers more difficult.
So we first need to make sure the approach is maintainable in a predictable
and consistent way. This is what I just mentioned in my reply to Phil on
the same thread [1], and I discuss it at greater length in a separate post
[2].
I want to add specifically in this reply that I believe that this
suggestion (the auto-updated leverage of a slightly extended jdk-build
approach) brings us also a step closer to completely reproducible builds.

- Johan

[1] https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/053076.html
[2]
https://johanvos.wordpress.com/2025/03/27/building-a-jdk-including-openjfx-part-2/


On Wed, Mar 12, 2025 at 8:11?PM John Neffenger <john at status6.com> wrote:

> On 2/27/25 7:15 AM, Johan Vos wrote:
> > The POC I have for this (linux-only at the moment) is at
> > https://github.com/johanvos/jdk/tree/jfxpoc-blog
>
> That's very clever, Johan. I never thought of using the JDK repository
> as-is to build JavaFX. I agree it's "one of the most excellent build
> systems for software development today," so what a great idea to start
> with that!
>
> Your "proof of concept" repository builds successfully for me on Ubuntu
> 22.04 LTS and goes rather smoothly through the JavaFX modules:
>
>      Compiling up to 1 files for java.se
>   -> Compiling up to 312 files for javafx.base
>      Compiling up to 18 files for jdk.accessibility
>      Compiling up to 3 files for jdk.editpad
>      Compiling up to 904 files for jdk.hotspot.agent
>      Compiling up to 64 files for jdk.jconsole
>      Compiling up to 69 files for jdk.jpackage
>      Compiling up to 8 files for jdk.unsupported.desktop
>   -> Compiling up to 1695 files for javafx.graphics
>   -> Compiling up to 296 files for javafx.controls
>
> The only rough edges are the 'javac' notes about deprecated APIs and
> unchecked or unsafe operations in use by JavaFX. Also, as you note, the
> 'gcc' warnings are a bit jarring when you're accustomed to the sparse
> output of the JDK build by itself.
>
> After the build, the JavaFX JMOD files are found in the right place:
>
> $ ls build/linux-x86_64-server-release/images/jdk/jmods/javafx*
> build/linux-x86_64-server-release/images/jdk/jmods/javafx.base.jmod
> build/linux-x86_64-server-release/images/jdk/jmods/javafx.controls.jmod
> build/linux-x86_64-server-release/images/jdk/jmods/javafx.graphics.jmod
>
> and the runtime image includes over 4,000 JavaFX classes:
>
> $ jimage list build/linux-x86_64-server-release/images/jdk/lib/modules \
>      | grep javafx | wc -l
> 4009
>
> I tested it with a "Hello World" JavaFX application on Ubuntu 24.04 LTS,
> and it worked fine except for a minor error:
>
> $ opt/jdk/bin/java --enable-native-access=javafx.graphics \
>      -jar tmp/dist/hello-javafx-1.0.0.jar
> Mar 12, 2025 7:04:06 PM com.sun.javafx.css.StyleManager loadStylesheet
> WARNING: Resource "com/sun/javafx/scene/control/skin/modena/modena.css"
> not found.
> Hello World!
>
> So when can we switch?! :-)
>
> Thanks,
> John
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/929dc5ac/attachment.htm>

From jdv at openjdk.org  Fri Mar 28 09:02:04 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 28 Mar 2025 09:02:04 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
Message-ID: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>

SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

-------------

Commit messages:
 - 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on wayland

Changes: https://git.openjdk.org/jfx/pull/1745/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353163
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1745.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1745/head:pull/1745

PR: https://git.openjdk.org/jfx/pull/1745

From jdv at openjdk.org  Fri Mar 28 09:24:19 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 28 Mar 2025 09:24:19 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
Message-ID: <01M11uwQqoLFT1bQTf6EXoAyFX6reHPLSXE_H8iyI9I=.3413991e-43ba-4af5-8ea3-3d90cf072d95@github.com>

On Wed, 5 Mar 2025 18:19:53 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Allows MenuBar to be created in a background thread by delaying MenuBarSkin::rebuildUI() call until after the MenuBar becomes a part of the scene graph.
>
> Andy Goryachev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into 8350976.menubarskin.thread.safety
>  - spelling
>  - use system menu
>  - cleanup
>  - possible fix
>  - test

menuBar test passes even without the fix in macOS.
Is this expected behaviour? Product change looks common and not specific to any platform.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2760667518

From angorya at openjdk.org  Fri Mar 28 14:33:22 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 14:33:22 GMT
Subject: RFR: 8350976: MenuBarSkin: exception initializing in a background
 thread [v2]
In-Reply-To: <01M11uwQqoLFT1bQTf6EXoAyFX6reHPLSXE_H8iyI9I=.3413991e-43ba-4af5-8ea3-3d90cf072d95@github.com>
References: <rlPnhzYl_h3-WkWw7gxtdN8n5JKBVqgyu9HzWkUan8c=.5839a05f-0331-4437-bcc1-77169cdd00c8@github.com>
 <DPqHLvOKn7ua6rPjgS9pOY-fkcEf-N2wQmYtDoiWLb4=.71471049-457f-40ba-8bd5-562c8e550c04@github.com>
 <01M11uwQqoLFT1bQTf6EXoAyFX6reHPLSXE_H8iyI9I=.3413991e-43ba-4af5-8ea3-3d90cf072d95@github.com>
Message-ID: <vkXqfLiNdFdEOh3-vsdS7p9-oWqv22h-QAFsIJ278L0=.a4be4eb7-c9ae-417c-b74d-c5bcb8ace809@github.com>

On Fri, 28 Mar 2025 09:21:56 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> menuBar test passes even without the fix in macOS.

That's strange: for me it fails in the current master branch (the line number is different bc I just appended the test to the end of file).  macOS 15.3.2.


java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = MenuBar
	at javafx.graphics/com.sun.glass.ui.Application.checkEventThread(Application.java:440)
	at javafx.graphics/com.sun.glass.ui.Application.supportsSystemMenu(Application.java:719)
	at javafx.graphics/com.sun.javafx.tk.quantum.GlassSystemMenu.isSupported(GlassSystemMenu.java:91)
	at javafx.controls/javafx.scene.control.skin.MenuBarSkin.rebuildUI(MenuBarSkin.java:822)
	at javafx.controls/javafx.scene.control.skin.MenuBarSkin.<init>(MenuBarSkin.java:232)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1727#issuecomment-2761531100

From angorya at openjdk.org  Fri Mar 28 14:34:26 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 14:34:26 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <gsK0ZxLVyYXyLwujwRX2NJVru6LSN9PxmJ4ujE5bVkU=.580feee1-7404-4c08-ac6f-561c3539900a@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1745#pullrequestreview-2725751999

From angorya at openjdk.org  Fri Mar 28 14:41:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 14:41:18 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <xR0nZCTgry0haXcdy8J4jTJJ21ytkoc15bbSXX7YmRk=.6cc7baee-e201-4551-aae7-ff1b44b59305@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

Gradle Wrapper Validation step failed - could you re-start the job?  I suspect github does not like mornings.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1745#issuecomment-2761561445

From lkostyra at openjdk.org  Fri Mar 28 14:57:21 2025
From: lkostyra at openjdk.org (Lukasz Kostyra)
Date: Fri, 28 Mar 2025 14:57:21 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v7]
In-Reply-To: <Jaoe_JBj_cdjv_3HdA2Znp_MEvqRqDaaFRnfiLfAejE=.ef17ef46-fc13-458d-ae0e-ea9b820118fa@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <_RYIqjzt0brJVoSliQ6wp55WTaGXq5hePcW_IzuvIRA=.dab9fe0f-4141-4843-ade9-860f90cd7b4e@github.com>
 <Gx57z0w_0Xt9ZYdCzNLzeQfxaK-6hzyUqky__mdNdQI=.bbceee45-b9c6-4ac1-9b5e-33dbce7535bb@github.com>
 <Jaoe_JBj_cdjv_3HdA2Znp_MEvqRqDaaFRnfiLfAejE=.ef17ef46-fc13-458d-ae0e-ea9b820118fa@github.com>
Message-ID: <PI6LLIt8M_T2UJ3fIBjddOhorxwPp1Ox9DmaFk7cn6k=.f028ce91-47af-4c1a-858a-2ea2ea3a7f2d@github.com>

On Thu, 27 Mar 2025 13:14:27 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 207:
>> 
>>> 205: {
>>> 206:     addPair(GLASS_TEXT_PLAIN, CF_UNICODETEXT);
>>> 207:     addPair(GLASS_TEXT_PLAIN_LOCALE, CF_UNICODETEXT);
>> 
>> Seems like those changes made JFX unaware of text data ready to be pasted from "outside" - running your test program and trying to paste something to a TextBox (ex. in `HelloTextBoxClipboard`) doesn't work anymore (Paste popup menu option is disabled, Ctrl+V does nothing, whereas both were possible to do on master). I checked that these mime stuff changes are at fault.
>> 
>> My guess now would be that these mime_stuff changes have to be reverted and the actual change should happen as we request Clipboard data - probably a condition changing clipboard format `cf` from `CF_TEXT` and `CF_OEMTEXT` to `CF_UNICODETEXT` right before we call `me.Load()` in `PopMemory()`. Please check if that is in fact the case before committing though, I'm not 100% sure if that would work.
>> 
>> If that works, a comment explaining why we do this clipboard format swap would also come in handy for future generations.
>
> I can't check if replacing cf with CF_UNICODETEXT there works, as probably that flavor is already always prioritized.
> 
> My test for the early NUL terminator explicitly only sets CF_TEXT, but is converted to unicode.

I did give it some tries and it did indeed seem to prioritize `CF_UNICODETEXT`. I suspect we could leave it be without any extra conditions or changes then.

Let's revert the mime_stuff changes then, because they do break something, and then leave it as it is.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2018831343

From oschmidtmer at openjdk.org  Fri Mar 28 15:10:46 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Fri, 28 Mar 2025 15:10:46 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v8]
In-Reply-To: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
Message-ID: <sW4JEpN1Q8woljItgozxh2JlhyC1NQjSFsNjcEVK7jU=.d8f6ec8e-4dae-4859-9534-4e340a2ba9d6@github.com>

> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
> 
> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.

Oliver Schmidtmer 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 nine additional commits since the last revision:

 - revert to original mime types
 - Merge remote-tracking branch 'remotes/origin/master' into JDK-8281384
 - readding flavors with changed mapping
 - remove non unicode textformats
 - format and unneeded var removed
 - cleanup
 - search NUL terminator in native code
 - check both UTF16 bytes
 - JDK-8281384: Random chars on paste from Windows clipboard

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1724/files
  - new: https://git.openjdk.org/jfx/pull/1724/files/7330b8da..3a4eb33a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=07
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=06-07

  Stats: 6079 lines in 106 files changed: 4047 ins; 1426 del; 606 mod
  Patch: https://git.openjdk.org/jfx/pull/1724.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724

PR: https://git.openjdk.org/jfx/pull/1724

From martinfox656 at gmail.com  Fri Mar 28 16:26:37 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Fri, 28 Mar 2025 09:26:37 -0700
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
 <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
 <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>
Message-ID: <9F065E4B-F67A-40E2-9D3D-CAF9225CE191@gmail.com>

I?ve been able to reproduce this inside a debugger on my Mac every eighth try or so.

I?m not sure what I?m seeing is all that helpful. Your reproducing case is inducing a stack overflow exception. If the exception occurs while Parent.updateCachedBounds is executing the StackPane will be left in a bad state. This leads to the dirtyChildrenCount exceeding the number of children and then Parent.updateCachedBounds will start throwing the same AIOOBE on every layout pulse.

At least in my debug runs it?s all about the timing of the stack overflow. That probably doesn?t explain why your production app is getting into the same bad state.

And you?re right, this has nothing to do with the Alert. I was confused by the gap between when the exception occurs and when it?s reported.

Martin

> On Mar 26, 2025, at 9:20?PM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> Interesting, that exception does not happen on my macOS 15.3 system. The reproducer somehow also doesn't seem to trigger the IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. On Windows, the large alert is shown as a broken stage with no content and controls for me, which I guess is slightly better than an exception, but also not ideal.  So it seems like the reproducer behavior depends a lot on the specific system.
> 
> On 26/03/2025 19:35, Martin Fox wrote:
>> Christopher,
>> 
>> Yes, there might be more than one issue here. On the Mac the call to Stage.showAndWait is making its way into the Mac glass code where an exception is being thrown leading to another call to Stage.showAndWait. I?ve attached the repeating block below. I don?t see that pattern in the Windows stack trace you provided.
>> 
>> Martin
>> 
>> 	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException>(Application.java:452)
>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2 <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2>(Native Method)
>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds>(MacWindow.java:70)
>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds>(Window.java:589)
>> 	at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds <mailto:javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds>(WindowStage.java:304)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply <mailto:javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply>(Window.java:1566)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window.applyBounds <mailto:javafx.graphics at 25-internal/javafx.stage.Window.applyBounds>(Window.java:1424)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window.adjustSize <mailto:javafx.graphics at 25-internal/javafx.stage.Window.adjustSize>(Window.java:327)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene <mailto:javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene>(Window.java:284)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated <mailto:javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated>(Window.java:1215)
>> 	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid <mailto:javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid>(BooleanPropertyBase.java:110)
>> 	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set <mailto:javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set>(BooleanPropertyBase.java:145)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window.setShowing <mailto:javafx.graphics at 25-internal/javafx.stage.Window.setShowing>(Window.java:1235)
>> 	at javafx.graphics at 25-internal/javafx.stage.Window.show <mailto:javafx.graphics at 25-internal/javafx.stage.Window.show>(Window.java:1250)
>> 	at javafx.graphics at 25-internal/javafx.stage.Stage.show <mailto:javafx.graphics at 25-internal/javafx.stage.Stage.show>(Stage.java:272)
>> 	at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait <mailto:javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait>(Stage.java:427)
>> 	at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait <mailto:javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait>(HeavyweightDialog.java:162)
>> 	at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait <mailto:javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait>(Dialog.java:347)
>> 	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>> 
>>> On Mar 26, 2025, at 10:49?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>> 
>>> Hey Martin,
>>> 
>>> thank you for looking into this. The initial StackOverflow is a result of me forcing to reproduce the bounds IndexOutOfBoundsException. The StackOverflow can be ignored, it was merely the best method I found to transition the scene graph into a state where the IndexOutOfBoundsExceptions are thrown. The OOBs are not thrown in every run though, it sometimes takes a few tries. In our production application, the same IndexOutOfBoundsExceptions also occur randomly without a previous exception. You can probably also reproduce the IndexOutOfBoundsExceptions without the StackOverflow, but reproducing it was very fragile, so I didn't look into it more.
>>> 
>>> I don't think it has necessarily something to do with the alert bounds as the IndexOutOfBoundsException is also thrown if you don't show an alert at all. The constant IndexOutOfBoundsExceptions in combination with the alert showAndWait was how our application entered the original crashing state. So the reproducer is more like a two-in-one.
>>> 
>>> Best
>>> Christopher Schnick
>>> 
>>> On 26/03/2025 18:33, Martin Fox wrote:
>>>> Yes, thank you Christopher for providing a reproducible test case!
>>>> 
>>>> I was able to trigger the problem on my Mac on the first try. Since I?m using a modified version of JavaFX the system didn?t crash but instead hit a Java stack overflow error and produced a very long stack trace.
>>>> 
>>>> At least on the Mac the problem seems to be that you?re trying to pop an Alert containing a long stack trace. While trying to adjust the Alert?s bounds JavaFX is throwing another exception but I?m not sure why. I?ll continue to look into it.
>>>> 
>>>> Thanks again,
>>>> Martin
>>>> 
>>>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>>>>> 
>>>>> Thank you, Christopher, for clarification!
>>>>>  
>>>>> Personally, I would consider this to be a problem with the application design: the code should limit the number of alerts shown to the user.  Do you really want the user to click through hundreds of alerts?
>>>>>  
>>>>> Nevertheless, you are right about the need for the platform to gracefully handle the case of too many nested event loops - by throwing an exception with a meaningful message, as Martin proposed in https://github.com/openjdk/jfx/pull/1741
>>>>>  
>>>>> Cheers,
>>>>> -andy
>>>>>  
>>>>>  
>>>>>  
>>>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>> Date: Tuesday, March 25, 2025 at 11:52
>>>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>>>> Subject: Re: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>>>> 
>>>>> Hey Andy,
>>>>> 
>>>>> so I think I was able to reproduce this issue for our application.
>>>>> 
>>>>> There are two main factors how this can happen:
>>>>> - We use an alert-based error reporter, meaning that we have a default uncaught exception handler set for all threads which will showAndWait an Alert with the exception message
>>>>> - As I reported yesterday with https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, there are some rare exceptions that can occur in a normal event loop without interference of the application, probably because of a small bug in the bounds calculation code
>>>>> 
>>>>> If you combine these two factors, you will end up with an infinite loop of the showAndWait entering a nested event loop, the event loop throwing an internal exception, and the uncaught exception handler starting the same loop with another alert. I don't think this is a bad implementation from our side, the only thing that we can improve is to maybe check how deep the uncaught exception loop is in to prevent this from occurring indefinitely. But I would argue this can happen to any application. Here is a sample code, based on the reproducer from the OutOfBounds report from yesterday:
>>>>> 
>>>>> import javafx.application.Application;
>>>>> import javafx.application.Platform;
>>>>> import javafx.scene.Scene;
>>>>> import javafx.scene.control.Alert;
>>>>> import javafx.scene.control.Button;
>>>>> import javafx.scene.layout.Region;
>>>>> import javafx.scene.layout.StackPane;
>>>>> import javafx.scene.layout.VBox;
>>>>> import javafx.stage.Stage;
>>>>>  
>>>>> import java.io.IOException;
>>>>> import java.util.Arrays;
>>>>>  
>>>>> public class ParentBoundsBug extends Application {
>>>>>  
>>>>>     @Override
>>>>>     public void start(Stage stage) throws IOException {
>>>>>         Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
>>>>>             throwable.printStackTrace();
>>>>>  
>>>>>             if (Platform.isFxApplicationThread()) {
>>>>>                 var alert = new Alert(Alert.AlertType.ERROR);
>>>>>                 alert.setHeaderText(throwable.getMessage());
>>>>>                 alert.setContentText(Arrays.toString(throwable.getStackTrace()));
>>>>>                 alert.showAndWait();
>>>>>             } else {
>>>>>                 // Do some other error handling for non-platform threads
>>>>>                 // Probably just show the alert with a runLater()
>>>>>  
>>>>>                 // For this example, there are no exceptions outside the platform thread
>>>>>             }
>>>>>         });
>>>>>  
>>>>>         // Run delayed as Application::reportException will only be called for exceptions
>>>>>         // after the application has started
>>>>>         Platform.runLater(() -> {
>>>>>             Scene scene = new Scene(createContent(), 640, 480);
>>>>>             stage.setScene(scene);
>>>>>             stage.show();
>>>>>             stage.centerOnScreen();
>>>>>         });
>>>>>     }
>>>>>  
>>>>>     private Region createContent() {
>>>>>         var b1 = new Button("Click me!");
>>>>>         var b2 = new Button("Click me!");
>>>>>         var vbox = new VBox(b1, b2);
>>>>>         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>         });
>>>>>         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>         });
>>>>>         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>         });
>>>>>  
>>>>>         var stack = new StackPane(vbox, new StackPane());
>>>>>         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>         });
>>>>>         return stack;
>>>>>     }
>>>>>  
>>>>>     public static void main(String[] args) {
>>>>>         launch();
>>>>>     }
>>>>> }
>>>>> 
>>>>> If the same OutOfBounds exception from the reported I linked happens in the bounds calculation, which happens approximately 1/5 runs for me, this application will enter new event loops until it crashes. If the OutOfBounds doesn't trigger, it will just throw a StackOverflow but won't continue the infinite loop of nested event loops. So for the reproducer it is important to try a few times until you get the described OutOfBounds.
>>>>> 
>>>>> I attached the stacktrace of how this fails. The initial StackOverflow causes infinitely many following exceptions in the nested event loop.
>>>>> 
>>>>> Best
>>>>> Christopher Schnick
>>>>> 
>>>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>>>> Dear Christopher:
>>>>>  
>>>>> Were you able to root cause why your application enters that many nested event loops?
>>>>>  
>>>>> I believe a well-behaved application should never experience that, unless there is some design flaw or a bug.
>>>>>  
>>>>> -andy
>>>>>  
>>>>>  
>>>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>> Date: Monday, March 10, 2025 at 19:45
>>>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>>>> Subject: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>>>> 
>>>>> Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.
>>>>> 
>>>>> I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
>>>>> From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
>>>>> And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.
>>>>> 
>>>>> Best
>>>>> Christopher Schnick
>>>>> 
>>>>> On 10/03/2025 18:51, Andy Goryachev wrote:
>>>>> This looks to me like it might be hitting the (native) thread stack size limit.
>>>>>  
>>>>> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>>>>>  
>>>>>      * An application may enter several nested loops recursively. There's no
>>>>>      * limit of recursion other than that imposed by the native stack size.
>>>>>  
>>>>>  
>>>>> -andy
>>>>>  
>>>>>  
>>>>>  
>>>>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>>>> Date: Monday, March 10, 2025 at 10:10
>>>>> To: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>>>> Subject: Re: JVM crashes on macOS when entering too many nested event loops
>>>>> 
>>>>> Hi Christopher,
>>>>> 
>>>>> I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
>>>>> I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.
>>>>> 
>>>>> Martin
>>>>> 
>>>>> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>>>> > 
>>>>> > Hello,
>>>>> > 
>>>>> > I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>>>>> > 
>>>>> > As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>>>>> > 
>>>>> > Best
>>>>> > Christopher Schnick<hs_err_pid.txt>
>>>>> 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/566508e5/attachment-0001.htm>

From zelmidaoui at openjdk.org  Fri Mar 28 17:28:22 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 28 Mar 2025 17:28:22 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
 [v2]
In-Reply-To: <_GBgcXsaw4VmQS4OLGW125SmKeJnndxV7I7lbdo_seM=.cd2f2be5-07de-4a67-aebb-3bef5b2e24a3@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
 <_GBgcXsaw4VmQS4OLGW125SmKeJnndxV7I7lbdo_seM=.cd2f2be5-07de-4a67-aebb-3bef5b2e24a3@github.com>
Message-ID: <AkrieKqa-LoKGiJUz0G_pyHh9psnV1Wnonm2pmsfkKc=.2450c253-7c53-419a-835a-06509bb787ad@github.com>

On Tue, 25 Mar 2025 22:41:59 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> looks good!
> 
> please update the copyright year in the modified files. 1 reviewer is probably enough.

Done,
Can I integrate ?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1743#issuecomment-2761989807

From zelmidaoui at openjdk.org  Fri Mar 28 17:28:22 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 28 Mar 2025 17:28:22 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
 [v2]
In-Reply-To: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
Message-ID: <8q1P4wpAktROQ_zAuThC3vCunOx1azWnVFNXZEdL2CA=.05e0c572-b7f8-4863-913e-94da7b02ef8f@github.com>

> With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess

Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1743/files
  - new: https://git.openjdk.org/jfx/pull/1743/files/cb085b8d..e73d9312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1743&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1743&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1743.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1743/head:pull/1743

PR: https://git.openjdk.org/jfx/pull/1743

From angorya at openjdk.org  Fri Mar 28 17:51:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 17:51:40 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
 [v2]
In-Reply-To: <8q1P4wpAktROQ_zAuThC3vCunOx1azWnVFNXZEdL2CA=.05e0c572-b7f8-4863-913e-94da7b02ef8f@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
 <8q1P4wpAktROQ_zAuThC3vCunOx1azWnVFNXZEdL2CA=.05e0c572-b7f8-4863-913e-94da7b02ef8f@github.com>
Message-ID: <_ra6EQKSlhh-b_2r05tQ61PwgEN2PkWYip2kYi7vWlE=.c2444b88-479c-46af-8f3b-62fc6be8afcb@github.com>

On Fri, 28 Mar 2025 17:28:22 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1743#pullrequestreview-2726278457

From duke at openjdk.org  Fri Mar 28 18:01:24 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Mar 2025 18:01:24 GMT
Subject: RFR: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
 [v2]
In-Reply-To: <8q1P4wpAktROQ_zAuThC3vCunOx1azWnVFNXZEdL2CA=.05e0c572-b7f8-4863-913e-94da7b02ef8f@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
 <8q1P4wpAktROQ_zAuThC3vCunOx1azWnVFNXZEdL2CA=.05e0c572-b7f8-4863-913e-94da7b02ef8f@github.com>
Message-ID: <sWKuMO0--bISaIsbOwlHsTKpJ-WrrO68CUH8cXG-4qY=.29a56e79-cc7e-470a-8b2b-1ac41c38ad0e@github.com>

On Fri, 28 Mar 2025 17:28:22 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

>> With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess
>
> Ziad El Midaoui has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

@Ziad-Mid 
Your change (at version e73d93127cb738cb234a23f09a12351d0c96f3ad) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1743#issuecomment-2762065152

From crschnick at xpipe.io  Fri Mar 28 18:06:52 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Fri, 28 Mar 2025 19:06:52 +0100
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <9F065E4B-F67A-40E2-9D3D-CAF9225CE191@gmail.com>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
 <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
 <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>
 <9F065E4B-F67A-40E2-9D3D-CAF9225CE191@gmail.com>
Message-ID: <a4a7adf8-a19b-4981-afc6-ef288583145d@xpipe.io>

So I tried various different things to reproduce it without the 
StackOverflow, but no success so far. But I can definitely tell you from 
many user issue reports that this issue frequently happens. Looking at 
the logs when this happens, there were no other exceptions reported when 
this happens.

It however doesn't leave the node in a bad state in most cases, in 
production this exception usually only occurs once without the same 
exception happening in later pulses. Having a loop of pulse exceptions 
that happened with the JVM crash is rarer. It breaks the layout however, 
so a restart is required.

I would already be happy with a simple index check to not throw an OOB 
exception in the implementation, I don't think there's any harm in that. 
While the StackOverflow is a very made-up case, I think even for that it 
would be good if it wouldn't throw exceptions in later pulses if you're 
looking for a justification on why to implement an index check.

On 28/03/2025 17:26, Martin Fox wrote:
> I?ve been able to reproduce this inside a debugger on my Mac every 
> eighth try or so.
>
> I?m not sure what I?m seeing is all that helpful. Your reproducing 
> case is inducing a stack overflow exception. If the exception occurs 
> while Parent.updateCachedBounds is executing the StackPane will be 
> left in a bad state. This leads to the dirtyChildrenCount exceeding 
> the number of children and then Parent.updateCachedBounds will start 
> throwing the same AIOOBE on every layout pulse.
>
> At least in my debug runs it?s all about the timing of the stack 
> overflow. That probably doesn?t explain why your production app is 
> getting into the same bad state.
>
> And you?re right, this has nothing to do with the Alert. I was 
> confused by the gap between when the exception occurs and when it?s 
> reported.
>
> Martin
>
>> On Mar 26, 2025, at 9:20?PM, Christopher Schnick <crschnick at xpipe.io> 
>> wrote:
>>
>> Interesting, that exception does not happen on my macOS 15.3 system. 
>> The reproducer somehow also doesn't seem to trigger the 
>> IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. 
>> On Windows, the large alert is shown as a broken stage with no 
>> content and controls for me, which I guess is slightly better than an 
>> exception, but also not ideal.? So it seems like the reproducer 
>> behavior depends a lot on the specific system.
>>
>> On 26/03/2025 19:35, Martin Fox wrote:
>>> Christopher,
>>>
>>> Yes, there might be more than one issue here. On the Mac the call to 
>>> Stage.showAndWait is making its way into the Mac glass code where an 
>>> exception is being thrown leading to another call to 
>>> Stage.showAndWait. I?ve attached the repeating block below. I don?t 
>>> see that pattern in the Windows stack trace you provided.
>>>
>>> Martin
>>>
>>> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>> at 
>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>> at 
>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>> at 
>>> javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException(Application.java:452)
>>> at 
>>> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2(Native 
>>> Method)
>>> at 
>>> javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds(MacWindow.java:70)
>>> at 
>>> javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds(Window.java:589)
>>> at 
>>> javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds(WindowStage.java:304)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply(Window.java:1566)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window.applyBounds(Window.java:1424)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window.adjustSize(Window.java:327)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene(Window.java:284)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated(Window.java:1215)
>>> at 
>>> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
>>> at 
>>> javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window.setShowing(Window.java:1235)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Window.show(Window.java:1250)
>>> at javafx.graphics at 25-internal/javafx.stage.Stage.show(Stage.java:272)
>>> at 
>>> javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait(Stage.java:427)
>>> at 
>>> javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait(HeavyweightDialog.java:162)
>>> at 
>>> javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait(Dialog.java:347)
>>> at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>> at 
>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>> at 
>>> java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>>
>>>> On Mar 26, 2025, at 10:49?AM, Christopher Schnick 
>>>> <crschnick at xpipe.io> wrote:
>>>>
>>>> Hey Martin,
>>>>
>>>> thank you for looking into this. The initial StackOverflow is a 
>>>> result of me forcing to reproduce the bounds 
>>>> IndexOutOfBoundsException. The StackOverflow can be ignored, it was 
>>>> merely the best method I found to transition the scene graph into a 
>>>> state where the IndexOutOfBoundsExceptions are thrown. The OOBs are 
>>>> not thrown in every run though, it sometimes takes a few tries. In 
>>>> our production application, the same IndexOutOfBoundsExceptions 
>>>> also occur randomly without a previous exception. You can probably 
>>>> also reproduce the IndexOutOfBoundsExceptions without the 
>>>> StackOverflow, but reproducing it was very fragile, so I didn't 
>>>> look into it more.
>>>>
>>>> I don't think it has necessarily something to do with the alert 
>>>> bounds as the IndexOutOfBoundsException is also thrown if you don't 
>>>> show an alert at all. The constant IndexOutOfBoundsExceptions in 
>>>> combination with the alert showAndWait was how our application 
>>>> entered the original crashing state. So the reproducer is more like 
>>>> a two-in-one.
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>>> On 26/03/2025 18:33, Martin Fox wrote:
>>>>> Yes, thank you Christopher for providing a reproducible test case!
>>>>>
>>>>> I was able to trigger the problem on my Mac on the first try. 
>>>>> Since I?m using a modified version of JavaFX the system didn?t 
>>>>> crash but instead hit a Java stack overflow error and produced a 
>>>>> very long stack trace.
>>>>>
>>>>> At least on the Mac the problem seems to be that you?re trying to 
>>>>> pop an Alert containing a long stack trace. While trying to adjust 
>>>>> the Alert?s bounds JavaFX is throwing another exception but I?m 
>>>>> not sure why. I?ll continue to look into it.
>>>>>
>>>>> Thanks again,
>>>>> Martin
>>>>>
>>>>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev 
>>>>>> <andy.goryachev at oracle.com> wrote:
>>>>>>
>>>>>> Thank you, Christopher, for clarification!
>>>>>> Personally, I would consider this to be a problem with the 
>>>>>> application design: the code should limit the number of alerts 
>>>>>> shown to the user. Do you really want the user to click through 
>>>>>> hundreds of alerts?
>>>>>> Nevertheless, you are right about the need for the platform to 
>>>>>> gracefully handle the case of too many nested event loops - by 
>>>>>> throwing an exception with a meaningful message, as Martin 
>>>>>> proposed inhttps://github.com/openjdk/jfx/pull/1741
>>>>>> Cheers,
>>>>>> -andy
>>>>>>
>>>>>> *From:*Christopher Schnick <crschnick at xpipe.io>
>>>>>> *Date:*Tuesday, March 25, 2025 at 11:52
>>>>>> *To:*Andy Goryachev <andy.goryachev at oracle.com>
>>>>>> *Cc:*OpenJFX <openjfx-dev at openjdk.org>
>>>>>> *Subject:*Re: [External] : Re: JVM crashes on macOS when entering 
>>>>>> too many nested event loops
>>>>>>
>>>>>> Hey Andy,
>>>>>>
>>>>>> so I think I was able to reproduce this issue for our application.
>>>>>>
>>>>>> There are two main factors how this can happen:
>>>>>> - We use an alert-based error reporter, meaning that we have a 
>>>>>> default uncaught exception handler set for all threads which will 
>>>>>> showAndWait an Alert with the exception message
>>>>>> - As I reported yesterday 
>>>>>> withhttps://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, 
>>>>>> there are some rare exceptions that can occur in a normal event 
>>>>>> loop without interference of the application, probably because of 
>>>>>> a small bug in the bounds calculation code
>>>>>>
>>>>>> If you combine these two factors, you will end up with an 
>>>>>> infinite loop of the showAndWait entering a nested event loop, 
>>>>>> the event loop throwing an internal exception, and the uncaught 
>>>>>> exception handler starting the same loop with another alert. I 
>>>>>> don't think this is a bad implementation from our side, the only 
>>>>>> thing that we can improve is to maybe check how deep the uncaught 
>>>>>> exception loop is in to prevent this from occurring indefinitely. 
>>>>>> But I would argue this can happen to any application. Here is a 
>>>>>> sample code, based on the reproducer from the OutOfBounds report 
>>>>>> from yesterday:
>>>>>>
>>>>>> import javafx.application.Application;
>>>>>> import javafx.application.Platform;
>>>>>> import javafx.scene.Scene;
>>>>>> import javafx.scene.control.Alert;
>>>>>> import javafx.scene.control.Button;
>>>>>> import javafx.scene.layout.Region;
>>>>>> import javafx.scene.layout.StackPane;
>>>>>> import javafx.scene.layout.VBox;
>>>>>> import javafx.stage.Stage;
>>>>>> import java.io.IOException;
>>>>>> import java.util.Arrays;
>>>>>> public class ParentBoundsBug extends Application {
>>>>>> @Override
>>>>>> public void start(Stage stage) throws IOException {
>>>>>> ??????? Thread./setDefaultUncaughtExceptionHandler/((thread, 
>>>>>> throwable) -> {
>>>>>> ??????????? throwable.printStackTrace();
>>>>>> if (Platform./isFxApplicationThread/()) {
>>>>>> var alert = new Alert(Alert.AlertType./ERROR/);
>>>>>> ??????????????? alert.setHeaderText(throwable.getMessage());
>>>>>> ??????????????? 
>>>>>> alert.setContentText(Arrays./toString/(throwable.getStackTrace()));
>>>>>> ??????????????? alert.showAndWait();
>>>>>> ??????????? } else {
>>>>>> // Do some other error handling for non-platform threads
>>>>>> ??????????????? // Probably just show the alert with a runLater()
>>>>>> ??????????????? // For this example, there are no exceptions 
>>>>>> outside the platform thread
>>>>>> }
>>>>>> ??????? });
>>>>>> // Run delayed as Application::reportException will only be 
>>>>>> called for exceptions
>>>>>> ??????? // after the application has started
>>>>>> Platform./runLater/(() -> {
>>>>>> ??????????? Scene scene = new Scene(createContent(), 640, 480);
>>>>>> stage.setScene(scene);
>>>>>> stage.show();
>>>>>> stage.centerOnScreen();
>>>>>> ??????? });
>>>>>> ??? }
>>>>>> private Region createContent() {
>>>>>> var b1 = new Button("Click me!");
>>>>>> var b2 = new Button("Click me!");
>>>>>> var vbox = new VBox(b1, b2);
>>>>>> ??????? b1.boundsInParentProperty().addListener((observable, 
>>>>>> oldValue, newValue) -> {
>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>> ??????? });
>>>>>> ??????? b2.boundsInParentProperty().addListener((observable, 
>>>>>> oldValue, newValue) -> {
>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>> ??????? });
>>>>>> ??????? vbox.boundsInParentProperty().addListener((observable, 
>>>>>> oldValue, newValue) -> {
>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>> ??????? });
>>>>>> var stack = new StackPane(vbox, new StackPane());
>>>>>> ??????? stack.boundsInParentProperty().addListener((observable, 
>>>>>> oldValue, newValue) -> {
>>>>>> vbox.setVisible(!vbox.isVisible());
>>>>>> ??????? });
>>>>>> return stack;
>>>>>> ??? }
>>>>>> public static void main(String[] args) {
>>>>>> /launch/();
>>>>>> ??? }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> If the same OutOfBounds exception from the reported I linked 
>>>>>> happens in the bounds calculation, which happens approximately 
>>>>>> 1/5 runs for me, this application will enter new event loops 
>>>>>> until it crashes. If the OutOfBounds doesn't trigger, it will 
>>>>>> just throw a StackOverflow but won't continue the infinite loop 
>>>>>> of nested event loops. So for the reproducer it is important to 
>>>>>> try a few times until you get the described OutOfBounds.
>>>>>>
>>>>>> I attached the stacktrace of how this fails. The initial 
>>>>>> StackOverflow causes infinitely many following exceptions in the 
>>>>>> nested event loop.
>>>>>>
>>>>>> Best
>>>>>> Christopher Schnick
>>>>>>
>>>>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>>>>>
>>>>>>     Dear Christopher:
>>>>>>     Were you able to root cause why your application enters that
>>>>>>     many nested event loops?
>>>>>>     I believe a well-behaved application should never experience
>>>>>>     that, unless there is some design flaw or a bug.
>>>>>>     -andy
>>>>>>
>>>>>>     *From:*Christopher Schnick<crschnick at xpipe.io>
>>>>>>     <mailto:crschnick at xpipe.io>
>>>>>>     *Date:*Monday, March 10, 2025 at 19:45
>>>>>>     *To:*Andy Goryachev<andy.goryachev at oracle.com>
>>>>>>     <mailto:andy.goryachev at oracle.com>
>>>>>>     *Subject:*[External] : Re: JVM crashes on macOS when entering
>>>>>>     too many nested event loops
>>>>>>
>>>>>>     Our code and some libraries do enter some nested event loops
>>>>>>     at a few places when it makes sense, but we didn't do
>>>>>>     anything to explicitly provoke this, this occurred naturally
>>>>>>     in our application. So it would be nice if JavaFX could
>>>>>>     somehow guard against this, especially since crashing the JVM
>>>>>>     is probably the worst thing that can happen.
>>>>>>
>>>>>>     I looked at the documentation, but it seems like the public
>>>>>>     API at Platform::enterNestedEventLoop does not mention this.
>>>>>>     From my understanding, the method
>>>>>>     Platform::canStartNestedEventLoop is potentially the right
>>>>>>     method to indicate to the caller that the limit is close by
>>>>>>     returning false.
>>>>>>     And even if something like an exception is thrown when a
>>>>>>     nested event loop is started while it is close to the limit,
>>>>>>     that would still be much better than a direct crash.
>>>>>>
>>>>>>     Best
>>>>>>     Christopher Schnick
>>>>>>
>>>>>>     On 10/03/2025 18:51, Andy Goryachev wrote:
>>>>>>
>>>>>>         This looks to me like it might be hitting the (native)
>>>>>>         thread stack size limit.
>>>>>>         c.s.glass.ui.Application::enterNestedEventLoop() even
>>>>>>         warns about it:
>>>>>>         * An application may enter several nested loops
>>>>>>         recursively. There's no
>>>>>>         * limit of recursion other than that imposed by the
>>>>>>         native stack size.
>>>>>>         -andy
>>>>>>
>>>>>>         *From:*openjfx-dev<openjfx-dev-retn at openjdk.org>
>>>>>>         <mailto:openjfx-dev-retn at openjdk.org>on behalf of Martin
>>>>>>         Fox<martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>>>>>         *Date:*Monday, March 10, 2025 at 10:10
>>>>>>         *To:*Christopher Schnick<crschnick at xpipe.io>
>>>>>>         <mailto:crschnick at xpipe.io>
>>>>>>         *Cc:*OpenJFX<openjfx-dev at openjdk.org>
>>>>>>         <mailto:openjfx-dev at openjdk.org>
>>>>>>         *Subject:*Re: JVM crashes on macOS when entering too many
>>>>>>         nested event loops
>>>>>>
>>>>>>         Hi Christopher,
>>>>>>
>>>>>>         I was able to reproduce this crash. I wrote a small
>>>>>>         routine that recursively calls itself in a runLater block
>>>>>>         and then enters a nested event loop. The program crashes
>>>>>>         when creating loop 254. I?m not sure where that limit
>>>>>>         comes from so it?s possible that consuming some other
>>>>>>         system resource could lower it. I couldn?t see any good
>>>>>>         way to determine how many loops are active by looking at
>>>>>>         the crash report since it doesn?t show the entire call stack.
>>>>>>         I did a quick trial on Linux and was able to create a lot
>>>>>>         more loops (over 600) but then started seeing erratic
>>>>>>         behavior and errors coming from the Java VM. The behavior
>>>>>>         was variable unlike on the Mac which always crashes when
>>>>>>         creating loop 254.
>>>>>>
>>>>>>         Martin
>>>>>>
>>>>>>         > On Mar 7, 2025, at 6:24?AM, Christopher
>>>>>>         Schnick<crschnick at xpipe.io> <mailto:crschnick at xpipe.io>wrote:
>>>>>>         >
>>>>>>         > Hello,
>>>>>>         >
>>>>>>         > I have attached a JVM fatal error log that seemingly
>>>>>>         was caused by our JavaFX application entering too many
>>>>>>         nested event loops, which macOS apparently doesn't like.
>>>>>>         >
>>>>>>         > As far as I know, there is no upper limit defined on
>>>>>>         how often an event loop can be nested, so I think this is
>>>>>>         a bug that can occur in rare situations.
>>>>>>         >
>>>>>>         > Best
>>>>>>         > Christopher Schnick<hs_err_pid.txt>
>>>>>>
>>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/f1c14386/attachment-0001.htm>

From zelmidaoui at openjdk.org  Fri Mar 28 18:16:20 2025
From: zelmidaoui at openjdk.org (Ziad El Midaoui)
Date: Fri, 28 Mar 2025 18:16:20 GMT
Subject: Integrated: 8340004: [TestBug] Call
 ModuleLayer.Controller::enableNativeAccess directly rather than via reflection
In-Reply-To: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
References: <FcGVoiN2nWcCgvHBZXUQ4KSHdL32VWJhruHng-Z7_r0=.5f19a4a7-9df7-41f1-8edf-f83f7f1e83fd@github.com>
Message-ID: <htO1vzb3s59rOhh4v1lvwdF5DbfMhd_6YDvc_tzEsuI=.f876dcd0-de1e-44d9-bdbc-625d3ade6961@github.com>

On Tue, 25 Mar 2025 22:24:51 GMT, Ziad El Midaoui <zelmidaoui at openjdk.org> wrote:

> With the minimum JDK set to 22, the reflection calls is replaced with direct calls to enableNativeAccess

This pull request has now been integrated.

Changeset: ff777c7a
Author:    Ziad El Midaoui <zelmidaoui at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.org/jfx/commit/ff777c7abb0f491152d172f20cfc3dd6d76d5339
Stats:     18 lines in 2 files changed: 0 ins; 12 del; 6 mod

8340004: [TestBug] Call ModuleLayer.Controller::enableNativeAccess directly rather than via reflection

Reviewed-by: angorya

-------------

PR: https://git.openjdk.org/jfx/pull/1743

From kcr at openjdk.org  Fri Mar 28 18:23:44 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 18:23:44 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
 <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
Message-ID: <BcblWjS2LAWIXb1WwNnzLAub8jMNw3QZvkoaWMy4TVE=.772edd50-ef1e-4511-95a9-f1f0e515b284@github.com>

On Wed, 26 Mar 2025 14:11:34 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> The tests show that only LF "\n" is rendered as a new line, there is no need to add more restrictions that is not needed
>> and the same was tested by @andy-goryachev-oracle previously in the comments and it confirms the same.
>
> That doesn't sound like a compelling reason to me. In fact, it makes it seems like a bug in JavaFX that a line break is only rendered with `\n`, but not with `\r\n` or `\r`.
> 
> In any case, the goal here is to (semantically) transform a string such that it doesn't contain line breaks, and line breaks come in three different usual forms. Our goal should always be to do the right thing, and not stop half-way and rely on unspecified rendering quirks for the rest.

Option 1 is intentionally the status quo, and matches what Swing's JComponent does, although @mstr2 is right that this isn't documented. An RFE to treat `\r` or `\r\n` as a newline could be considered in the future. We wouldn't do that as part of this PR.

So for _this_ PR, the question is what characters should be elided for the prompt text of a `TextField` so that multiple lines as a single line? Limiting this to stripping `\n` is sufficient given the current implementation, unless and until something else changes. Also, it matches what the existing implementation tries to do when it modifies the actual property value.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2019136526

From angorya at openjdk.org  Fri Mar 28 18:40:01 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 18:40:01 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
Message-ID: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>

Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.

The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.

A possible improvement could be to output a data URL

`data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`

so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)

-------------

Commit messages:
 - prefix
 - Merge remote-tracking branch 'origin/master' into 8328716.screenshots
 - Merge remote-tracking branch 'origin/master' into 8328716.screenshots
 - Merge branch 'master' into 8328716.screenshots
 - Merge branch 'master' into 8328716.screenshots
 - capture all pixels
 - Merge branch 'master' into 8328716.screenshots
 - 8328716: [TestBug] Screen capturing utility for failed tests

Changes: https://git.openjdk.org/jfx/pull/1746/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328716
  Stats: 118 lines in 2 files changed: 117 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From angorya at openjdk.org  Fri Mar 28 19:25:59 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 19:25:59 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window for
 manual tests
Message-ID: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>

Provides the base class for manual tests which displays the test instructions, the UI under test, and the Pass/Fail buttons.

Uses `EmojiTest` to illustrate the use of the new class.

Example:


public class ManualTestExample extends ManualTestWindow {
    public ManualTestExample() {
        super(
            "Manual Test Example",
            """
            Instructions:
            1. you will see a button named "Test"
            2. press the button
            3. verify that the button can be pressed""",
            400, 250
        );
     }

     public static void main(String[] args) throws Exception {
         launch(args);
     }

     @Override
     protected Node createContent() {
         return new Button("Test");
     }
}


![Screenshot 2025-03-28 at 11 50 16](https://github.com/user-attachments/assets/b44a7eb1-d98f-44a5-b13e-612b31c94c60)

-------------

Commit messages:
 - cleanup
 - 2025
 - Merge remote-tracking branch 'origin/master' into 8319555.manual
 - Merge branch 'master' into 8319555.manual
 - Merge branch 'master' into 8319555.manual
 - Merge remote-tracking branch 'origin/master' into 8319555.manual
 - Merge remote-tracking branch 'origin/8319555.manual' into 8319555.manual
 - removed example
 - cleanup
 - whitespace
 - ... and 9 more: https://git.openjdk.org/jfx/compare/ff777c7a...8f23a763

Changes: https://git.openjdk.org/jfx/pull/1747/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319555
  Stats: 351 lines in 8 files changed: 290 ins; 47 del; 14 mod
  Patch: https://git.openjdk.org/jfx/pull/1747.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1747/head:pull/1747

PR: https://git.openjdk.org/jfx/pull/1747

From martinfox656 at gmail.com  Fri Mar 28 20:06:43 2025
From: martinfox656 at gmail.com (Martin Fox)
Date: Fri, 28 Mar 2025 13:06:43 -0700
Subject: [External] : Re: JVM crashes on macOS when entering too many
 nested event loops
In-Reply-To: <a4a7adf8-a19b-4981-afc6-ef288583145d@xpipe.io>
References: <6f326d6d-6069-43fe-800d-a01583c7558c@xpipe.io>
 <DEE5BE59-8CB7-46A0-9DBC-70CBF0756759@gmail.com>
 <BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com>
 <8778bda9-69a9-4393-9ea9-642df4a93304@xpipe.io>
 <DM6PR10MB30179CEC6B7069ADD0AD2101E5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <226e4247-b39b-4a3c-bcbd-912f663a0219@xpipe.io>
 <DM6PR10MB301706BE497AFA1E391C016EE5A72@DM6PR10MB3017.namprd10.prod.outlook.com>
 <9560C9BE-BC2F-4F0D-B914-425969699179@gmail.com>
 <e709b633-6c49-4623-a15f-50a294d56e2a@xpipe.io>
 <6532F614-D25B-4C55-9519-4DE1CD8629E0@gmail.com>
 <53b467d6-d40e-46bd-8a15-56ddf2c9f55f@xpipe.io>
 <9F065E4B-F67A-40E2-9D3D-CAF9225CE191@gmail.com>
 <a4a7adf8-a19b-4981-afc6-ef288583145d@xpipe.io>
Message-ID: <CB995A83-E9E7-497E-815E-5D414368A614@gmail.com>

This isn?t an area of the code that I?m familiar with. Searching for updateCachedBounds in the bug database shows that there?s some history here so maybe someone with more experience can chime in.

> On Mar 28, 2025, at 11:06?AM, Christopher Schnick <crschnick at xpipe.io> wrote:
> 
> So I tried various different things to reproduce it without the StackOverflow, but no success so far. But I can definitely tell you from many user issue reports that this issue frequently happens. Looking at the logs when this happens, there were no other exceptions reported when this happens.
> 
> It however doesn't leave the node in a bad state in most cases, in production this exception usually only occurs once without the same exception happening in later pulses. Having a loop of pulse exceptions that happened with the JVM crash is rarer. It breaks the layout however, so a restart is required.
> 
> I would already be happy with a simple index check to not throw an OOB exception in the implementation, I don't think there's any harm in that. While the StackOverflow is a very made-up case, I think even for that it would be good if it wouldn't throw exceptions in later pulses if you're looking for a justification on why to implement an index check.
> 
> On 28/03/2025 17:26, Martin Fox wrote:
>> I?ve been able to reproduce this inside a debugger on my Mac every eighth try or so.
>> 
>> I?m not sure what I?m seeing is all that helpful. Your reproducing case is inducing a stack overflow exception. If the exception occurs while Parent.updateCachedBounds is executing the StackPane will be left in a bad state. This leads to the dirtyChildrenCount exceeding the number of children and then Parent.updateCachedBounds will start throwing the same AIOOBE on every layout pulse.
>> 
>> At least in my debug runs it?s all about the timing of the stack overflow. That probably doesn?t explain why your production app is getting into the same bad state.
>> 
>> And you?re right, this has nothing to do with the Alert. I was confused by the gap between when the exception occurs and when it?s reported.
>> 
>> Martin
>> 
>>> On Mar 26, 2025, at 9:20?PM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>> 
>>> Interesting, that exception does not happen on my macOS 15.3 system. The reproducer somehow also doesn't seem to trigger the IndexOutOfBoundsExceptions on macOS for me, only on Windows so far. On Windows, the large alert is shown as a broken stage with no content and controls for me, which I guess is slightly better than an exception, but also not ideal.  So it seems like the reproducer behavior depends a lot on the specific system.
>>> 
>>> On 26/03/2025 19:35, Martin Fox wrote:
>>>> Christopher,
>>>> 
>>>> Yes, there might be more than one issue here. On the Mac the call to Stage.showAndWait is making its way into the Mac glass code where an exception is being thrown leading to another call to Stage.showAndWait. I?ve attached the repeating block below. I don?t see that pattern in the Windows stack trace you provided.
>>>> 
>>>> Martin
>>>> 
>>>> 	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.Application.reportException>(Application.java:452)
>>>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2 <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds2>(Native Method)
>>>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.mac.MacWindow._setBounds>(MacWindow.java:70)
>>>> 	at javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds <mailto:javafx.graphics at 25-internal/com.sun.glass.ui.Window.setBounds>(Window.java:589)
>>>> 	at javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds <mailto:javafx.graphics at 25-internal/com.sun.javafx.tk.quantum.WindowStage.setBounds>(WindowStage.java:304)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply <mailto:javafx.graphics at 25-internal/javafx.stage.Window$TKBoundsConfigurator.apply>(Window.java:1566)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window.applyBounds <mailto:javafx.graphics at 25-internal/javafx.stage.Window.applyBounds>(Window.java:1424)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window.adjustSize <mailto:javafx.graphics at 25-internal/javafx.stage.Window.adjustSize>(Window.java:327)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene <mailto:javafx.graphics at 25-internal/javafx.stage.Window.sizeToScene>(Window.java:284)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated <mailto:javafx.graphics at 25-internal/javafx.stage.Window$12.invalidated>(Window.java:1215)
>>>> 	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid <mailto:javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.markInvalid>(BooleanPropertyBase.java:110)
>>>> 	at javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set <mailto:javafx.base at 25-internal/javafx.beans.property.BooleanPropertyBase.set>(BooleanPropertyBase.java:145)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window.setShowing <mailto:javafx.graphics at 25-internal/javafx.stage.Window.setShowing>(Window.java:1235)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Window.show <mailto:javafx.graphics at 25-internal/javafx.stage.Window.show>(Window.java:1250)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Stage.show <mailto:javafx.graphics at 25-internal/javafx.stage.Stage.show>(Stage.java:272)
>>>> 	at javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait <mailto:javafx.graphics at 25-internal/javafx.stage.Stage.showAndWait>(Stage.java:427)
>>>> 	at javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait <mailto:javafx.controls at 25-internal/javafx.scene.control.HeavyweightDialog.showAndWait>(HeavyweightDialog.java:162)
>>>> 	at javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait <mailto:javafx.controls at 25-internal/javafx.scene.control.Dialog.showAndWait>(Dialog.java:347)
>>>> 	at ParentBoundsBug.lambda$start$0(ParentBoundsBug.java:25)
>>>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:663)
>>>> 	at java.base/java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:658)
>>>> 
>>>>> On Mar 26, 2025, at 10:49?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>>>> 
>>>>> Hey Martin,
>>>>> 
>>>>> thank you for looking into this. The initial StackOverflow is a result of me forcing to reproduce the bounds IndexOutOfBoundsException. The StackOverflow can be ignored, it was merely the best method I found to transition the scene graph into a state where the IndexOutOfBoundsExceptions are thrown. The OOBs are not thrown in every run though, it sometimes takes a few tries. In our production application, the same IndexOutOfBoundsExceptions also occur randomly without a previous exception. You can probably also reproduce the IndexOutOfBoundsExceptions without the StackOverflow, but reproducing it was very fragile, so I didn't look into it more.
>>>>> 
>>>>> I don't think it has necessarily something to do with the alert bounds as the IndexOutOfBoundsException is also thrown if you don't show an alert at all. The constant IndexOutOfBoundsExceptions in combination with the alert showAndWait was how our application entered the original crashing state. So the reproducer is more like a two-in-one.
>>>>> 
>>>>> Best
>>>>> Christopher Schnick
>>>>> 
>>>>> On 26/03/2025 18:33, Martin Fox wrote:
>>>>>> Yes, thank you Christopher for providing a reproducible test case!
>>>>>> 
>>>>>> I was able to trigger the problem on my Mac on the first try. Since I?m using a modified version of JavaFX the system didn?t crash but instead hit a Java stack overflow error and produced a very long stack trace.
>>>>>> 
>>>>>> At least on the Mac the problem seems to be that you?re trying to pop an Alert containing a long stack trace. While trying to adjust the Alert?s bounds JavaFX is throwing another exception but I?m not sure why. I?ll continue to look into it.
>>>>>> 
>>>>>> Thanks again,
>>>>>> Martin
>>>>>> 
>>>>>>> On Mar 25, 2025, at 12:16?PM, Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com> wrote:
>>>>>>> 
>>>>>>> Thank you, Christopher, for clarification!
>>>>>>>  
>>>>>>> Personally, I would consider this to be a problem with the application design: the code should limit the number of alerts shown to the user.  Do you really want the user to click through hundreds of alerts?
>>>>>>>  
>>>>>>> Nevertheless, you are right about the need for the platform to gracefully handle the case of too many nested event loops - by throwing an exception with a meaningful message, as Martin proposed in https://github.com/openjdk/jfx/pull/1741
>>>>>>>  
>>>>>>> Cheers,
>>>>>>> -andy
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>>>> Date: Tuesday, March 25, 2025 at 11:52
>>>>>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>>>>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>>>>>> Subject: Re: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>>>>>> 
>>>>>>> Hey Andy,
>>>>>>> 
>>>>>>> so I think I was able to reproduce this issue for our application.
>>>>>>> 
>>>>>>> There are two main factors how this can happen:
>>>>>>> - We use an alert-based error reporter, meaning that we have a default uncaught exception handler set for all threads which will showAndWait an Alert with the exception message
>>>>>>> - As I reported yesterday with https://mail.openjdk.org/pipermail/openjfx-dev/2025-March/052963.html, there are some rare exceptions that can occur in a normal event loop without interference of the application, probably because of a small bug in the bounds calculation code
>>>>>>> 
>>>>>>> If you combine these two factors, you will end up with an infinite loop of the showAndWait entering a nested event loop, the event loop throwing an internal exception, and the uncaught exception handler starting the same loop with another alert. I don't think this is a bad implementation from our side, the only thing that we can improve is to maybe check how deep the uncaught exception loop is in to prevent this from occurring indefinitely. But I would argue this can happen to any application. Here is a sample code, based on the reproducer from the OutOfBounds report from yesterday:
>>>>>>> 
>>>>>>> import javafx.application.Application;
>>>>>>> import javafx.application.Platform;
>>>>>>> import javafx.scene.Scene;
>>>>>>> import javafx.scene.control.Alert;
>>>>>>> import javafx.scene.control.Button;
>>>>>>> import javafx.scene.layout.Region;
>>>>>>> import javafx.scene.layout.StackPane;
>>>>>>> import javafx.scene.layout.VBox;
>>>>>>> import javafx.stage.Stage;
>>>>>>>  
>>>>>>> import java.io.IOException;
>>>>>>> import java.util.Arrays;
>>>>>>>  
>>>>>>> public class ParentBoundsBug extends Application {
>>>>>>>  
>>>>>>>     @Override
>>>>>>>     public void start(Stage stage) throws IOException {
>>>>>>>         Thread.setDefaultUncaughtExceptionHandler((thread, throwable) -> {
>>>>>>>             throwable.printStackTrace();
>>>>>>>  
>>>>>>>             if (Platform.isFxApplicationThread()) {
>>>>>>>                 var alert = new Alert(Alert.AlertType.ERROR);
>>>>>>>                 alert.setHeaderText(throwable.getMessage());
>>>>>>>                 alert.setContentText(Arrays.toString(throwable.getStackTrace()));
>>>>>>>                 alert.showAndWait();
>>>>>>>             } else {
>>>>>>>                 // Do some other error handling for non-platform threads
>>>>>>>                 // Probably just show the alert with a runLater()
>>>>>>>  
>>>>>>>                 // For this example, there are no exceptions outside the platform thread
>>>>>>>             }
>>>>>>>         });
>>>>>>>  
>>>>>>>         // Run delayed as Application::reportException will only be called for exceptions
>>>>>>>         // after the application has started
>>>>>>>         Platform.runLater(() -> {
>>>>>>>             Scene scene = new Scene(createContent(), 640, 480);
>>>>>>>             stage.setScene(scene);
>>>>>>>             stage.show();
>>>>>>>             stage.centerOnScreen();
>>>>>>>         });
>>>>>>>     }
>>>>>>>  
>>>>>>>     private Region createContent() {
>>>>>>>         var b1 = new Button("Click me!");
>>>>>>>         var b2 = new Button("Click me!");
>>>>>>>         var vbox = new VBox(b1, b2);
>>>>>>>         b1.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>>>         });
>>>>>>>         b2.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>>>         });
>>>>>>>         vbox.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>>>         });
>>>>>>>  
>>>>>>>         var stack = new StackPane(vbox, new StackPane());
>>>>>>>         stack.boundsInParentProperty().addListener((observable, oldValue, newValue) -> {
>>>>>>>             vbox.setVisible(!vbox.isVisible());
>>>>>>>         });
>>>>>>>         return stack;
>>>>>>>     }
>>>>>>>  
>>>>>>>     public static void main(String[] args) {
>>>>>>>         launch();
>>>>>>>     }
>>>>>>> }
>>>>>>> 
>>>>>>> If the same OutOfBounds exception from the reported I linked happens in the bounds calculation, which happens approximately 1/5 runs for me, this application will enter new event loops until it crashes. If the OutOfBounds doesn't trigger, it will just throw a StackOverflow but won't continue the infinite loop of nested event loops. So for the reproducer it is important to try a few times until you get the described OutOfBounds.
>>>>>>> 
>>>>>>> I attached the stacktrace of how this fails. The initial StackOverflow causes infinitely many following exceptions in the nested event loop.
>>>>>>> 
>>>>>>> Best
>>>>>>> Christopher Schnick
>>>>>>> 
>>>>>>> On 25/03/2025 18:28, Andy Goryachev wrote:
>>>>>>> Dear Christopher:
>>>>>>>  
>>>>>>> Were you able to root cause why your application enters that many nested event loops?
>>>>>>>  
>>>>>>> I believe a well-behaved application should never experience that, unless there is some design flaw or a bug.
>>>>>>>  
>>>>>>> -andy
>>>>>>>  
>>>>>>>  
>>>>>>> From: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>>>> Date: Monday, March 10, 2025 at 19:45
>>>>>>> To: Andy Goryachev <andy.goryachev at oracle.com> <mailto:andy.goryachev at oracle.com>
>>>>>>> Subject: [External] : Re: JVM crashes on macOS when entering too many nested event loops
>>>>>>> 
>>>>>>> Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.
>>>>>>> 
>>>>>>> I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.
>>>>>>> From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.
>>>>>>> And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.
>>>>>>> 
>>>>>>> Best
>>>>>>> Christopher Schnick
>>>>>>> 
>>>>>>> On 10/03/2025 18:51, Andy Goryachev wrote:
>>>>>>> This looks to me like it might be hitting the (native) thread stack size limit.
>>>>>>>  
>>>>>>> c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:
>>>>>>>  
>>>>>>>      * An application may enter several nested loops recursively. There's no
>>>>>>>      * limit of recursion other than that imposed by the native stack size.
>>>>>>>  
>>>>>>>  
>>>>>>> -andy
>>>>>>>  
>>>>>>>  
>>>>>>>  
>>>>>>> From: openjfx-dev <openjfx-dev-retn at openjdk.org> <mailto:openjfx-dev-retn at openjdk.org> on behalf of Martin Fox <martinfox656 at gmail.com> <mailto:martinfox656 at gmail.com>
>>>>>>> Date: Monday, March 10, 2025 at 10:10
>>>>>>> To: Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io>
>>>>>>> Cc: OpenJFX <openjfx-dev at openjdk.org> <mailto:openjfx-dev at openjdk.org>
>>>>>>> Subject: Re: JVM crashes on macOS when entering too many nested event loops
>>>>>>> 
>>>>>>> Hi Christopher,
>>>>>>> 
>>>>>>> I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I?m not sure where that limit comes from so it?s possible that consuming some other system resource could lower it. I couldn?t see any good way to determine how many loops are active by looking at the crash report since it doesn?t show the entire call stack.
>>>>>>> I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.
>>>>>>> 
>>>>>>> Martin
>>>>>>> 
>>>>>>> > On Mar 7, 2025, at 6:24?AM, Christopher Schnick <crschnick at xpipe.io> <mailto:crschnick at xpipe.io> wrote:
>>>>>>> > 
>>>>>>> > Hello,
>>>>>>> > 
>>>>>>> > I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.
>>>>>>> > 
>>>>>>> > As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.
>>>>>>> > 
>>>>>>> > Best
>>>>>>> > Christopher Schnick<hs_err_pid.txt>
>>>>>>> 
>>>>>> 
>>>> 
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250328/d8c32a34/attachment-0001.htm>

From kcr at openjdk.org  Fri Mar 28 20:23:41 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 20:23:41 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <Gv_g4uVJK7U2IH9xx9ETyiCnskM08UYOCwUVEYIIBuM=.ec2eb426-eef9-4e9c-a1dc-0d97338032bb@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

LGTM with one inline suggestion about adding the bug ID being used to skip this test (JDK-8350009).

Regarding [JDK-8350009](https://bugs.openjdk.org/browse/JDK-8350009), I was finally able to test this on my Ubuntu 24.04 VM after resetting the Wayland screencast token (I had some problem with my system earlier). After doing this, the test only hangs for me on JDK 23. When I run it on JDK 24 it now reliably passes for me.

More testing is needed, though, so go ahead and integrate this fix to skip the test on Wayland after adding the bug ID. If we then find out that it runs reliably on multiple systems when using JDK 24, you can fix [JDK-8350009](https://bugs.openjdk.org/browse/JDK-8350009) by adding the check for JDK version so that it will only skip on Wayland for JDK 23 and earllier.

tests/system/src/test/java/test/robot/javafx/embed/swing/SwingNodePlatformExitCrashTest.java line 57:

> 55:     @BeforeAll
> 56:     public static void skipShutDown() {
> 57:         Assumptions.assumeTrue(!Util.isOnWayland());

Please add `// JDK-8350009` in a comment, either at the end of this line or on a line by itself before this).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1745#pullrequestreview-2726639820
PR Review Comment: https://git.openjdk.org/jfx/pull/1745#discussion_r2019294250

From kcr at openjdk.org  Fri Mar 28 20:59:12 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 20:59:12 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
Message-ID: <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>

On Fri, 28 Mar 2025 18:43:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Provides the base class for manual tests which displays the test instructions, the UI under test, and the Pass/Fail buttons.
> 
> Uses `EmojiTest` to illustrate the use of the new class.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>      }
> 
>      public static void main(String[] args) throws Exception {
>          launch(args);
>      }
> 
>      @Override
>      protected Node createContent() {
>          return new Button("Test");
>      }
> }
> 
> 
> ![Screenshot 2025-03-28 at 11 50 16](https://github.com/user-attachments/assets/b44a7eb1-d98f-44a5-b13e-612b31c94c60)

Without using an IDE (which is the default use case for manual tests), how would someone compile and run these?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2762489090

From kcr at openjdk.org  Fri Mar 28 21:31:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 21:31:43 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>

On Fri, 28 Mar 2025 18:22:56 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> A possible improvement could be to output a data URL
> 
> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
> 
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)

I haven't tested it yet, but look forward to doing so.

My main comment is that this needs to be 'opt in' on a gradle property. Something like this (probably with a better name) :


gradle ... -PUSE_ROBOT=true -PSCREEN_DUMP=true


Or if we can figure out a good way to limit the number of tests that will be captured:


gradle ... -PUSE_ROBOT=true -PSCREEN_DUMP_LIMIT=10

tests/system/src/test/java/test/robot/javafx/scene/control/behavior/TextAreaBehaviorRobotTest.java line 40:

> 38:  * since the mapped functions require rendered text.
> 39:  */
> 40: @ExtendWith(ScreenCaptureTestWatcher.class)

A JUnit5 annotation seams like an easy way to mark our robot tests for capture. Are there any drawbacks with this approach?

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 44:

> 42: 
> 43: /**
> 44:  * Standard Test Watcher for Headful Tests (JUnit 5 Only).

I think the "JUnit 5 only" comment isn't needed. All of our system tests already use only JUnit 5.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 47:

> 45:  * <p>
> 46:  * This facility takes a screenshot of any failed test, then logs the base64-encoded screenshot
> 47:  * to {@code stderr}.

This should not be on by default, but should be "opt in" on a System property. I recommend defining a gradle property to do this and map it to that System property, much like we do for "UNSTABLE_TEST" and others.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 62:

> 60:  * -ea
> 61:  * }</pre>
> 62:  * <p>

I don't much like IDE-specific documentation in our class files.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 64:

> 62:  * <p>
> 63:  * WARNING: using this utility may significantly increase the size of your logs!
> 64:  * Make sure there is plenty of free disk space.

Given my earlier comment about this needing to be qualified by a system property, this comment should also go in `build.gradle` where the property is defined.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 67:

> 65:  */
> 66: // TODO investigate having a hard-coded or programmable via property limit on the number of
> 67: // captured screenshots.

I had the same thought. Given that each test runs in its own JVM, I can't think of a good way to do it other than recording information in a file in tests/system/build.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 71:

> 69:     @Override
> 70:     public void testAborted(ExtensionContext extensionContext, Throwable err) {
> 71:         err.printStackTrace();

Is this needed or is it just for debugging? We already get a stack trace when a test fails, so it might be redundant.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 76:

> 74:     @Override
> 75:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
> 76:         err.printStackTrace();

Same question as about about printing the stack trace.

tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 77:

> 75:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
> 76:         err.printStackTrace();
> 77:         System.err.println(generateScreenshot("Screenshot:{", "}"));

When does the `testFailed` method run? After a failing `@Test` method that throws the exception? What if there is more than one failing test? Ideally what we want is something that runs after all failing tests, but before the `@AfterEach` method.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1746#pullrequestreview-2726765623
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019373251
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019375500
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019376822
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019377220
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019381676
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019385645
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019386416
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019392578
PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019408150

From kcr at openjdk.org  Fri Mar 28 21:35:10 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 21:35:10 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <Zk2BSjP-gvEaAI0obsjGd2EyH6Y5qOPObAi6QczpsiY=.eafe235c-ddab-45c5-8cf3-b41626255e2f@github.com>

On Fri, 28 Mar 2025 21:21:11 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> A possible improvement could be to output a data URL
>> 
>> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
>> 
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 77:
> 
>> 75:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>> 76:         err.printStackTrace();
>> 77:         System.err.println(generateScreenshot("Screenshot:{", "}"));
> 
> When does the `testFailed` method run? After a failing `@Test` method that throws the exception? What if there is more than one failing test? Ideally what we want is something that runs after all failing tests, but before the `@AfterEach` method.

Or... maybe we really do want to take a screen dump for each failing test in a test class.

Also, what happens if one of the lifecycle methods is the one that throws the error (e.g., `Before` `After`, etc)?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2019426801

From kcr at openjdk.org  Fri Mar 28 21:39:15 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 21:39:15 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v5]
In-Reply-To: <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <dhLgGgv1RPlXIzSxq-9HBm64wrScfSGtB5Sk6YadG-M=.66d0f6b4-311e-4910-bacc-a6f30ef1b90f@github.com>
 <4ktgKW4EAB5r5MAYw4sheOvomMNGubuMMojy8rkDCyI=.151b31b0-cb94-4a77-a54c-a59540ee9d35@github.com>
Message-ID: <m9RWVMUAXmnjC_ZYOsQ3dHRWgLhgXn8Pnwtt5x21JCQ=.346179b3-f652-43b9-84c6-5a96f6a3ba65@github.com>

On Thu, 27 Mar 2025 17:44:17 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Martin Fox has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Removed unnecessary import
>>  - The max nested event loop constant is no longer public
>
> Since this fix has been expanded to all platforms, let's remove `[macos]` from the title of the JBS issue and PR.

> Do we still need a CSR @kevinrushforth ?

It's still a good idea, since we are throwing the exception in cases where we didn't use to. It will be a simple CSR with a risk level of "minimal" (since it's in a case where misbehavior is going to happen anyway).

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2762597100

From kcr at openjdk.org  Fri Mar 28 21:43:14 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 28 Mar 2025 21:43:14 GMT
Subject: RFR: 8335547: Support multi-line prompt text for TextArea [v4]
In-Reply-To: <BcblWjS2LAWIXb1WwNnzLAub8jMNw3QZvkoaWMy4TVE=.772edd50-ef1e-4511-95a9-f1f0e515b284@github.com>
References: <3aj3G2DX664bnyFH2LSp_37d087cD5ka3gA5RkYoQN8=.77408cdf-b228-4076-8c49-167a1ab38517@github.com>
 <CDdPLwm_Td3FWl9Ox4kfJCxRgEwpAYX6k1iIhxc9WIA=.3619b09e-11af-43a6-8ef9-ac7e3f7fbff6@github.com>
 <SACqj1maKQK7VJ7unHRqW8QEiI4QGcCJHowaUd9yTjI=.678843c9-de45-4979-83c6-d8d9b1d9f730@github.com>
 <4h1LiyfDsTi7u06VZO6_ffy4JYDZr7CW9UWkcejFDAg=.7fc889b6-e5da-4a67-9951-f1d1f4afcbbd@github.com>
 <Cejw4zeZ9GDa5ZckxI_y04ggrR3rUUPavsiLnFCkZXA=.b77514dc-c05f-4fcd-99bc-cb2d40c566df@github.com>
 <BcblWjS2LAWIXb1WwNnzLAub8jMNw3QZvkoaWMy4TVE=.772edd50-ef1e-4511-95a9-f1f0e515b284@github.com>
Message-ID: <YHzb5PGESIjFXzL0GHov66Oi_itr7COBnJ2uE2X1tJU=.5acf7694-8e7d-48d2-b53a-7641d139a63a@github.com>

On Fri, 28 Mar 2025 18:20:59 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> That doesn't sound like a compelling reason to me. In fact, it makes it seems like a bug in JavaFX that a line break is only rendered with `\n`, but not with `\r\n` or `\r`.
>> 
>> In any case, the goal here is to (semantically) transform a string such that it doesn't contain line breaks, and line breaks come in three different usual forms. Our goal should always be to do the right thing, and not stop half-way and rely on unspecified rendering quirks for the rest.
>
> Option 1 is intentionally the status quo, and matches what Swing's JComponent does, although @mstr2 is right that this isn't documented. An RFE to treat `\r` or `\r\n` as a newline could be considered in the future. We wouldn't do that as part of this PR.
> 
> So for _this_ PR, the question is what characters should be elided for the prompt text of a `TextField` so that multiple lines as a single line? Limiting this to stripping `\n` is sufficient given the current implementation, unless and until something else changes. Also, it matches what the existing implementation tries to do when it modifies the actual property value.

One thing I am curious about: I don't see a similar stripping of newlines in the text itself for TextField, and yet it does render the whole string as if the newline had been stripped. Do you know why we need to strip it from promptTextProperty explicitly and not from textProperty?

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1716#discussion_r2019299973

From angorya at openjdk.org  Fri Mar 28 23:09:29 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 23:09:29 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
Message-ID: <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>

On Fri, 28 Mar 2025 20:55:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Without using an IDE (which is the default use case for manual tests), how would someone compile and run these?

Frankly, I have no idea.  We might create a special module which contains common test code and utilities, I suppose.  Any suggestions will be greatly appreciated!

The following command line expectedly fails because it can't find `com.oracle.util.testing.ManualTestWindow`:

java --module-path=build/sdk/lib --add-modules=javafx.controls ./tests/manual/text/EmojiTest.java

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2762797964

From angorya at openjdk.org  Fri Mar 28 23:19:34 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 28 Mar 2025 23:19:34 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
Message-ID: <52smgs2IFoHbQO_NXhK9xbbxQbenQWX_xgA6tmZYc94=.ad68cbe5-0a09-4b07-b078-1ed50217675d@github.com>

On Fri, 28 Mar 2025 18:43:34 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Provides the base class for manual tests which displays the test instructions, the UI under test, and the Pass/Fail buttons.
> 
> Uses `EmojiTest` to illustrate the use of the new class.
> 
> Example:
> 
> 
> public class ManualTestExample extends ManualTestWindow {
>     public ManualTestExample() {
>         super(
>             "Manual Test Example",
>             """
>             Instructions:
>             1. you will see a button named "Test"
>             2. press the button
>             3. verify that the button can be pressed""",
>             400, 250
>         );
>      }
> 
>      public static void main(String[] args) throws Exception {
>          launch(args);
>      }
> 
>      @Override
>      protected Node createContent() {
>          return new Button("Test");
>      }
> }
> 
> 
> ![Screenshot 2025-03-28 at 11 50 16](https://github.com/user-attachments/assets/b44a7eb1-d98f-44a5-b13e-612b31c94c60)

On a related note, where is it documented how to run manual tests?

https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Testing
says nothing, still references JDK9 and JDK10 (though the content might still be true), and a link called "several items to work around module export during build and testing" under "Adding new packages in a modular world" section leads to the beginning of the document:

https://wiki.openjdk.org/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-UnderstandingaJDK9Modularworldmixedinourdeveloperbuild

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2762815048

From mstrauss at openjdk.org  Sat Mar 29 07:15:07 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 29 Mar 2025 07:15:07 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <1TFdcS-eoYUnbt6u0wQgIObc32IBb9HXP3Px23pk2KI=.bebc4cb6-34cf-4048-9635-39b72707f779@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
 <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>
 <2D8AESOO5ZU5qZqd54AeqslaONKZ5l6sy8bppg9W6oU=.7173a0a9-6149-4a94-b376-110b85a17a21@github.com>
 <1TFdcS-eoYUnbt6u0wQgIObc32IBb9HXP3Px23pk2KI=.bebc4cb6-34cf-4048-9635-39b72707f779@github.com>
Message-ID: <h8_QFEaMOlCLrlwfD1AYRv-ZTFsnc1sQvZy_h-Q8JU4=.08fdda01-eb51-444d-85bf-f254832c8215@github.com>

On Wed, 26 Mar 2025 21:48:23 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> That was just for deriving the `hpos` and `vpos` fields, which are no longer needed, in case `pos` was `null`.  The `null` check is now handled in `LabeledSkinBase`.
>> 
>> Of course we could think of some kind of derive option (how to derive LEFT + RIGHT?) or a way to remove one of these, but I think either way, it's outside the scope of this change.  I added the comment for future maintainers (I could have left it out, and we'd probably not be having this discussion).  
>> 
>> As it is, I don't think we should fix this as part of this change as it is really completely unrelated (and might need much more discussion and perhaps even a CSR...)
>> 
>> Perhaps I should remove the comment and instead we describe this in an issue?
>
> I agree: this change is out of scope for this PR.

I suggest to remove the comment and file a JBS ticket.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2019741389

From mstrauss at openjdk.org  Sat Mar 29 07:15:08 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 29 Mar 2025 07:15:08 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
In-Reply-To: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
Message-ID: <jEunlga-ZuEiUOh4htx7_VEE3HOSYLAYgpVEJqqZ49E=.c25c055d-9e18-468d-8e14-5d141129a8be@github.com>

On Sat, 22 Mar 2025 12:20:17 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
> 
> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
> 
> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 394:

> 392: 
> 393:     /*
> 394:      * TitledSpanSkin borrows the Label calculations from LabeledSkinBase, but

typo: TitledPaneSkin

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2019740931

From jhendrikx at openjdk.org  Sat Mar 29 09:10:52 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 29 Mar 2025 09:10:52 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
 [v2]
In-Reply-To: <h8_QFEaMOlCLrlwfD1AYRv-ZTFsnc1sQvZy_h-Q8JU4=.08fdda01-eb51-444d-85bf-f254832c8215@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <RimHzlZ3FJ5bofeN5Mox6-XauZ-RWlZS9yxGi6F_HTw=.50f325cb-b695-4ab0-a9d3-48d5abdce47a@github.com>
 <LaXEcUrDS7QR_Nn7vq2pYjhuLjzlEoWLfO8QqtKHWqg=.d510440c-0ba9-4790-a050-96ac2e2a5c5c@github.com>
 <QEwMNE6evgojV6UiGdzxVoHmdN35VR_OChPbFJveiOY=.891716ad-a88b-43af-b71a-d82d9527709e@github.com>
 <2D8AESOO5ZU5qZqd54AeqslaONKZ5l6sy8bppg9W6oU=.7173a0a9-6149-4a94-b376-110b85a17a21@github.com>
 <1TFdcS-eoYUnbt6u0wQgIObc32IBb9HXP3Px23pk2KI=.bebc4cb6-34cf-4048-9635-39b72707f779@github.com>
 <h8_QFEaMOlCLrlwfD1AYRv-ZTFsnc1sQvZy_h-Q8JU4=.08fdda01-eb51-444d-85bf-f254832c8215@github.com>
Message-ID: <k2mS9v7qsvvT_cNaCkYGSl-vWAQVUAOPjw-Hm_RJugA=.1e16c5a2-1950-4ee5-9ac9-7bd10b79c60f@github.com>

On Sat, 29 Mar 2025 07:10:22 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> I agree: this change is out of scope for this PR.
>
> I suggest to remove the comment and file a JBS ticket.

Comment removed then

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2019758060

From jhendrikx at openjdk.org  Sat Mar 29 09:10:51 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 29 Mar 2025 09:10:51 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
 [v2]
In-Reply-To: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
Message-ID: <ditUVXWS-lvgiaOtQuB8yoAj039B2KEK8WUw_kMftqc=.39fb3b6a-c691-49bd-a13a-20be87adfc6b@github.com>

> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
> 
> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
> 
> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.

John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1742/files
  - new: https://git.openjdk.org/jfx/pull/1742/files/b65002ac..1c5c50a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1742&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1742&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jfx/pull/1742.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1742/head:pull/1742

PR: https://git.openjdk.org/jfx/pull/1742

From jhendrikx at openjdk.org  Sat Mar 29 09:10:52 2025
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Sat, 29 Mar 2025 09:10:52 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
 [v2]
In-Reply-To: <jEunlga-ZuEiUOh4htx7_VEE3HOSYLAYgpVEJqqZ49E=.c25c055d-9e18-468d-8e14-5d141129a8be@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <jEunlga-ZuEiUOh4htx7_VEE3HOSYLAYgpVEJqqZ49E=.c25c055d-9e18-468d-8e14-5d141129a8be@github.com>
Message-ID: <nG-L6hiKgrPUrEV9eMAgwUJsrVou-Fb0fFaeN9fMxbM=.e304b81f-c10b-47e3-9950-b57354f630c3@github.com>

On Sat, 29 Mar 2025 07:08:40 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TitledPaneSkin.java line 394:
> 
>> 392: 
>> 393:     /*
>> 394:      * TitledSpanSkin borrows the Label calculations from LabeledSkinBase, but
> 
> typo: TitledPaneSkin

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1742#discussion_r2019757961

From mstrauss at openjdk.org  Sat Mar 29 09:15:17 2025
From: mstrauss at openjdk.org (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 29 Mar 2025 09:15:17 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
 [v2]
In-Reply-To: <ditUVXWS-lvgiaOtQuB8yoAj039B2KEK8WUw_kMftqc=.39fb3b6a-c691-49bd-a13a-20be87adfc6b@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <ditUVXWS-lvgiaOtQuB8yoAj039B2KEK8WUw_kMftqc=.39fb3b6a-c691-49bd-a13a-20be87adfc6b@github.com>
Message-ID: <rf8CNy-doDIofXJ0VIeUxPE1jc2lhTtv7Z4dBLGoIiA=.73843f09-65be-4796-900b-c17f77b5fd94@github.com>

On Sat, 29 Mar 2025 09:10:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
>> 
>> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
>> 
>> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by mstrauss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1742#pullrequestreview-2727323147

From jvos at openjdk.org  Sat Mar 29 10:13:07 2025
From: jvos at openjdk.org (Johan Vos)
Date: Sat, 29 Mar 2025 10:13:07 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <b5biFie_Xi0L_TGM2CMxvk9-A1mJaLrBm21ykwqWQDM=.1f261b01-6492-4eb0-8588-ac727dc0f527@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

I'm a bit worried with disabling the test, as there is no guarantee the bug will be fixed. Since the issue is clearly identified, I would rather go for fixing JDK-8350009 instead of disabling the test.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1745#issuecomment-2763273543

From thiago.sayao at gmail.com  Sat Mar 29 11:26:31 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 29 Mar 2025 08:26:31 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
 <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
Message-ID: <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>

@Christopher Schnick <crschnick at xpipe.io>

Hi, did you open a bug? I have a fix for this.

Thanks

-- Thiago.

Em seg., 17 de mar. de 2025 ?s 09:49, Christopher Schnick <
crschnick at xpipe.io> escreveu:

> So on Windows at least, it will change the width temporarily and then
> revert back to the original width value. So you will receive two width
> change events if you listen to the stage width property. The maximized
> property is not changed.
>
> I guess this also not optimal handling of this. Ideally, no changes would
> be made in that case.
> On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
>
> Hi Christopher,
>
> It seems like a simple fix.
>
> How does it behave on other platforms? Does it ignore the resize, restore
> the window to its unmaximized state before resizing, or keep it maximized
> while adjusting the unmaximized size.
>
> -- Thiago
>
>
>
>
>
>
> Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick <
> crschnick at xpipe.io> escreveu:
>
>> Hello,
>>
>> we encountered an issue on Linux where resizing the stage while it is
>> maximized breaks the size of the scene. You can see a video of this at
>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that
>> the stage size is modified.
>>
>> When doing this, it temporarily or permanently switches to the size the
>> stage had prior to being maximized, leading to either a flicker or a
>> permanently broken scene that has the wrong size. This happens on Gnome and
>> KDE for me with the latest JavaFX ea version.
>>
>> Here is a simple reproducer:
>>
>> import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.Region;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
>> import java.io.IOException;import java.util.Base64;
>> public class MaximizeLinuxBug extends Application {
>>
>>     @Override    public void start(Stage stage) throws IOException {
>>         Scene scene = new Scene(createContent(), 640, 480);
>>         var s = "data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>>         scene.getStylesheets().add(s);
>>         stage.setTitle("Hello!");
>>         stage.setScene(scene);
>>         stage.show();
>>         stage.centerOnScreen();
>>         stage.setMaximized(true);
>>     }
>>
>>     private String createCss() {
>>         return """                * {                -fx-border-color: red;                -fx-border-width: 1;                }                """;
>>     }
>>
>>     private Region createContent() {
>>         var button = new Button("Click me!");
>>         button.setOnAction(event -> {
>>             var w = button.getScene().getWindow();
>>             w.setWidth(w.getWidth() - 1);
>>             event.consume();
>>         });
>>         var stack = new StackPane(button);
>>         return stack;
>>     }
>>
>>     public static void main(String[] args) {
>>         launch();
>>     }
>> }
>>
>>
>> Best
>> Christopher Schnick
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250329/7fe3dbbb/attachment-0001.htm>

From thiago.sayao at gmail.com  Sat Mar 29 12:24:30 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 29 Mar 2025 09:24:30 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
 <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
 <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>
Message-ID: <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>

I did not find a bug report, so I did one and provided a fix:

https://github.com/openjdk/jfx/pull/1748



Em s?b., 29 de mar. de 2025 ?s 08:26, Thiago Milczarek Say?o <
thiago.sayao at gmail.com> escreveu:

> @Christopher Schnick <crschnick at xpipe.io>
>
> Hi, did you open a bug? I have a fix for this.
>
> Thanks
>
> -- Thiago.
>
> Em seg., 17 de mar. de 2025 ?s 09:49, Christopher Schnick <
> crschnick at xpipe.io> escreveu:
>
>> So on Windows at least, it will change the width temporarily and then
>> revert back to the original width value. So you will receive two width
>> change events if you listen to the stage width property. The maximized
>> property is not changed.
>>
>> I guess this also not optimal handling of this. Ideally, no changes would
>> be made in that case.
>> On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
>>
>> Hi Christopher,
>>
>> It seems like a simple fix.
>>
>> How does it behave on other platforms? Does it ignore the resize, restore
>> the window to its unmaximized state before resizing, or keep it maximized
>> while adjusting the unmaximized size.
>>
>> -- Thiago
>>
>>
>>
>>
>>
>>
>> Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick <
>> crschnick at xpipe.io> escreveu:
>>
>>> Hello,
>>>
>>> we encountered an issue on Linux where resizing the stage while it is
>>> maximized breaks the size of the scene. You can see a video of this at
>>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that
>>> the stage size is modified.
>>>
>>> When doing this, it temporarily or permanently switches to the size the
>>> stage had prior to being maximized, leading to either a flicker or a
>>> permanently broken scene that has the wrong size. This happens on Gnome and
>>> KDE for me with the latest JavaFX ea version.
>>>
>>> Here is a simple reproducer:
>>>
>>> import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.Region;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
>>> import java.io.IOException;import java.util.Base64;
>>> public class MaximizeLinuxBug extends Application {
>>>
>>>     @Override    public void start(Stage stage) throws IOException {
>>>         Scene scene = new Scene(createContent(), 640, 480);
>>>         var s = "data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>>>         scene.getStylesheets().add(s);
>>>         stage.setTitle("Hello!");
>>>         stage.setScene(scene);
>>>         stage.show();
>>>         stage.centerOnScreen();
>>>         stage.setMaximized(true);
>>>     }
>>>
>>>     private String createCss() {
>>>         return """                * {                -fx-border-color: red;                -fx-border-width: 1;                }                """;
>>>     }
>>>
>>>     private Region createContent() {
>>>         var button = new Button("Click me!");
>>>         button.setOnAction(event -> {
>>>             var w = button.getScene().getWindow();
>>>             w.setWidth(w.getWidth() - 1);
>>>             event.consume();
>>>         });
>>>         var stack = new StackPane(button);
>>>         return stack;
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>         launch();
>>>     }
>>> }
>>>
>>>
>>> Best
>>> Christopher Schnick
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250329/fcf38f55/attachment.htm>

From tsayao at openjdk.org  Sat Mar 29 12:26:44 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 29 Mar 2025 12:26:44 GMT
Subject: RFR: 8353223: [Linux] - Maximized windows do not retain correct size
 when resized programmatically
Message-ID: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>

When a window is maximized, if only the width or height is programmatically set, the window will retain its current maximized dimension (either height or width) as is, unless the other dimension is also explicitly set.

This is consistent with what Gtk does.

-------------

Commit messages:
 - Restore unrelated line break
 - Forgot previous test
 - [Linux] - Maximized windows do not retain correct size when resized programmatically

Changes: https://git.openjdk.org/jfx/pull/1748/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1748&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353223
  Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1748.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1748/head:pull/1748

PR: https://git.openjdk.org/jfx/pull/1748

From tsayao at openjdk.org  Sat Mar 29 12:26:44 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 29 Mar 2025 12:26:44 GMT
Subject: RFR: 8353223: [Linux] - Maximized windows do not retain correct
 size when resized programmatically
In-Reply-To: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
References: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
Message-ID: <WrCurgHu2AEuLbv3u9A5zyMxqLJx--1hjC1DMRDTOSY=.8969b25e-4aab-45f1-9c47-403eb9a71392@github.com>

On Sat, 29 Mar 2025 12:17:29 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When a window is maximized, if only the width or height is programmatically set, the window will retain its current maximized dimension (either height or width) as is, unless the other dimension is also explicitly set.
> 
> This is consistent with what Gtk does.

I initially pasted the wrong JBS issue on the title because I was multitasking :)

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1748#issuecomment-2763340964

From crschnick at xpipe.io  Sat Mar 29 12:52:41 2025
From: crschnick at xpipe.io (Christopher Schnick)
Date: Sat, 29 Mar 2025 13:52:41 +0100
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
 <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
 <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>
 <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>
Message-ID: <323c78ad-a7ab-4a6f-a362-b7e84a4d1938@xpipe.io>

Thanks, yeah I did not submit an issue there because I don't like the 
bug report website form. But that is another story.

I looked at the PR, seems to be pretty straightforward. Thinking about 
this, I have not tested how it behaves with the fullscreen property 
instead of the maximized property as I rarely use that. Maybe that also 
needs to be covered.

On 29/03/2025 13:24, Thiago Milczarek Say?o wrote:
> I did not find a bug report, so I did one and provided a fix:
>
> https://github.com/openjdk/jfx/pull/1748
>
>
>
> Em s?b., 29 de mar. de 2025 ?s 08:26, Thiago Milczarek Say?o 
> <thiago.sayao at gmail.com> escreveu:
>
>     @Christopher Schnick <mailto:crschnick at xpipe.io>
>
>     Hi, did you open a bug? I have a fix for this.
>
>     Thanks
>
>     -- Thiago.
>
>     Em seg., 17 de mar. de 2025 ?s 09:49, Christopher Schnick
>     <crschnick at xpipe.io> escreveu:
>
>         So on Windows at least, it will change the width temporarily
>         and then revert back to the original width value. So you will
>         receive two width change events if you listen to the stage
>         width property. The maximized property is not changed.
>
>         I guess this also not optimal handling of this. Ideally, no
>         changes would be made in that case.
>
>         On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
>>         Hi Christopher,
>>
>>         It seems like a simple fix.
>>
>>         How does it behave on other platforms? Does it ignore the
>>         resize, restore the window to its unmaximized state before
>>         resizing, or keep it maximized while adjusting the
>>         unmaximized size.
>>
>>         -- Thiago
>>
>>
>>
>>
>>
>>
>>         Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick
>>         <crschnick at xpipe.io> escreveu:
>>
>>             Hello,
>>
>>             we encountered an issue on Linux where resizing the stage
>>             while it is maximized breaks the size of the scene. You
>>             can see a video of this at
>>             https://github.com/xpipe-io/xpipe/issues/485 . The root
>>             cause is that the stage size is modified.
>>
>>             When doing this, it temporarily or permanently switches
>>             to the size the stage had prior to being maximized,
>>             leading to either a flicker or a permanently broken scene
>>             that has the wrong size. This happens on Gnome and KDE
>>             for me with the latest JavaFX ea version.
>>
>>             Here is a simple reproducer:
>>
>>             import javafx.application.Application;
>>             import javafx.scene.Scene;
>>             import javafx.scene.control.Button;
>>             import javafx.scene.layout.Region;
>>             import javafx.scene.layout.StackPane;
>>             import javafx.stage.Stage;
>>
>>             import java.io.IOException;
>>             import java.util.Base64;
>>
>>             public class MaximizeLinuxBugextends Application {
>>
>>                  @Override public void start(Stage stage)throws IOException {
>>                      Scene scene =new Scene(createContent(),640,480);
>>                      var s ="data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>>                      scene.getStylesheets().add(s);
>>                      stage.setTitle("Hello!");
>>                      stage.setScene(scene);
>>                      stage.show();
>>                      stage.centerOnScreen();
>>                      stage.setMaximized(true);
>>                  }
>>
>>                  private StringcreateCss() {
>>                      return """ * { -fx-border-color: red; -fx-border-width:
>>             1; } """;
>>                  }
>>
>>                  private RegioncreateContent() {
>>                      var button =new Button("Click me!");
>>                      button.setOnAction(event -> {
>>                          var w =button.getScene().getWindow();
>>                          w.setWidth(w.getWidth() -1);
>>                          event.consume();
>>                      });
>>                      var stack =new StackPane(button);
>>                      return stack;
>>                  }
>>
>>                  public static void main(String[] args) {
>>                      launch();
>>                  }
>>             }
>>
>>
>>             Best
>>             Christopher Schnick
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250329/aca96724/attachment.htm>

From tsayao at openjdk.org  Sat Mar 29 13:42:18 2025
From: tsayao at openjdk.org (Thiago Milczarek Sayao)
Date: Sat, 29 Mar 2025 13:42:18 GMT
Subject: RFR: 8353223: [Linux] - Maximized windows do not retain correct
 size when resized programmatically
In-Reply-To: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
References: <fyAnSvERX-bOxTg7GDQoZYL7dBzysh556fZeLNZXpWM=.bc011f1d-76b6-4d34-9dc4-026ea44d87d6@github.com>
Message-ID: <QFwOeKhP-SuyKkRPkKgbbKPNGJVXGNgflYYjZQoho-s=.789eac55-dbb4-489b-ae2c-5c8281754b35@github.com>

On Sat, 29 Mar 2025 12:17:29 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

> When a window is maximized, if only the width or height is programmatically set, the window will retain its current maximized dimension (either height or width) as is, unless the other dimension is also explicitly set.
> 
> This is consistent with what Gtk does.

I'm having second thoughts about this, begin that resize should be ignored if the window is maximized.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1748#issuecomment-2763368749

From thiago.sayao at gmail.com  Sat Mar 29 13:44:01 2025
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Sat, 29 Mar 2025 10:44:01 -0300
Subject: Resizing stage while it is maximized breaks scene size on Linux
In-Reply-To: <323c78ad-a7ab-4a6f-a362-b7e84a4d1938@xpipe.io>
References: <bd3dd87c-138b-4330-aaf1-54f91d32e3a9@xpipe.io>
 <CAAP_wumg0w5vEsSBgOBz5NcCbjvCVzqTKzvrJRP4W2QqTc4Ymw@mail.gmail.com>
 <825de66a-8e70-4489-b9eb-ef7a2123e317@xpipe.io>
 <CAAP_wun8zNphQP27DxNtiDV18+tv-4EW_dYYq33PhDrPFEx0FA@mail.gmail.com>
 <CAAP_wuk0=58Uv6dGUyB7TJHKUzNgqTwaxRq7UEhxAUVCfxrscw@mail.gmail.com>
 <323c78ad-a7ab-4a6f-a362-b7e84a4d1938@xpipe.io>
Message-ID: <CAAP_wu=Q5D-Yv0SMpqqhhTCFCfaYQPowtaYxUWEenWFiUL=ukg@mail.gmail.com>

The documentation states:

"If this Window is an instance of Stage, changing this attribute will not
visually affect the Window while fullScreen is true, but will be honored by
the Window once fullScreen becomes false."

Maybe it should also be the case for maximized state.



Em s?b., 29 de mar. de 2025 ?s 09:52, Christopher Schnick <
crschnick at xpipe.io> escreveu:

> Thanks, yeah I did not submit an issue there because I don't like the bug
> report website form. But that is another story.
>
> I looked at the PR, seems to be pretty straightforward. Thinking about
> this, I have not tested how it behaves with the fullscreen property instead
> of the maximized property as I rarely use that. Maybe that also needs to be
> covered.
> On 29/03/2025 13:24, Thiago Milczarek Say?o wrote:
>
> I did not find a bug report, so I did one and provided a fix:
>
> https://github.com/openjdk/jfx/pull/1748
>
>
>
> Em s?b., 29 de mar. de 2025 ?s 08:26, Thiago Milczarek Say?o <
> thiago.sayao at gmail.com> escreveu:
>
>> @Christopher Schnick <crschnick at xpipe.io>
>>
>> Hi, did you open a bug? I have a fix for this.
>>
>> Thanks
>>
>> -- Thiago.
>>
>> Em seg., 17 de mar. de 2025 ?s 09:49, Christopher Schnick <
>> crschnick at xpipe.io> escreveu:
>>
>>> So on Windows at least, it will change the width temporarily and then
>>> revert back to the original width value. So you will receive two width
>>> change events if you listen to the stage width property. The maximized
>>> property is not changed.
>>>
>>> I guess this also not optimal handling of this. Ideally, no changes
>>> would be made in that case.
>>> On 17/03/2025 10:53, Thiago Milczarek Say?o wrote:
>>>
>>> Hi Christopher,
>>>
>>> It seems like a simple fix.
>>>
>>> How does it behave on other platforms? Does it ignore the resize,
>>> restore the window to its unmaximized state before resizing, or keep it
>>> maximized while adjusting the unmaximized size.
>>>
>>> -- Thiago
>>>
>>>
>>>
>>>
>>>
>>>
>>> Em dom., 16 de mar. de 2025 ?s 05:25, Christopher Schnick <
>>> crschnick at xpipe.io> escreveu:
>>>
>>>> Hello,
>>>>
>>>> we encountered an issue on Linux where resizing the stage while it is
>>>> maximized breaks the size of the scene. You can see a video of this at
>>>> https://github.com/xpipe-io/xpipe/issues/485 . The root cause is that
>>>> the stage size is modified.
>>>>
>>>> When doing this, it temporarily or permanently switches to the size the
>>>> stage had prior to being maximized, leading to either a flicker or a
>>>> permanently broken scene that has the wrong size. This happens on Gnome and
>>>> KDE for me with the latest JavaFX ea version.
>>>>
>>>> Here is a simple reproducer:
>>>>
>>>> import javafx.application.Application;import javafx.scene.Scene;import javafx.scene.control.Button;import javafx.scene.layout.Region;import javafx.scene.layout.StackPane;import javafx.stage.Stage;
>>>> import java.io.IOException;import java.util.Base64;
>>>> public class MaximizeLinuxBug extends Application {
>>>>
>>>>     @Override    public void start(Stage stage) throws IOException {
>>>>         Scene scene = new Scene(createContent(), 640, 480);
>>>>         var s = "data:text/css;base64," + Base64.getEncoder().encodeToString(createCss().getBytes());
>>>>         scene.getStylesheets().add(s);
>>>>         stage.setTitle("Hello!");
>>>>         stage.setScene(scene);
>>>>         stage.show();
>>>>         stage.centerOnScreen();
>>>>         stage.setMaximized(true);
>>>>     }
>>>>
>>>>     private String createCss() {
>>>>         return """                * {                -fx-border-color: red;                -fx-border-width: 1;                }                """;
>>>>     }
>>>>
>>>>     private Region createContent() {
>>>>         var button = new Button("Click me!");
>>>>         button.setOnAction(event -> {
>>>>             var w = button.getScene().getWindow();
>>>>             w.setWidth(w.getWidth() - 1);
>>>>             event.consume();
>>>>         });
>>>>         var stack = new StackPane(button);
>>>>         return stack;
>>>>     }
>>>>
>>>>     public static void main(String[] args) {
>>>>         launch();
>>>>     }
>>>> }
>>>>
>>>>
>>>> Best
>>>> Christopher Schnick
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/openjfx-dev/attachments/20250329/353582ab/attachment-0001.htm>

From kcr at openjdk.org  Mon Mar 31 12:57:21 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 12:57:21 GMT
Subject: RFR: 8353163: [XWayland] Disable SwingNodePlatformExitCrashTest on
 wayland
In-Reply-To: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
References: <2o_BDXwphZRgKE4vhr-JDy70tNmxCDnG7jrmQc87x4I=.e3d2420a-b993-4f8a-91e8-ad1ccffa2e47@github.com>
Message-ID: <YC827Cltd3EaV5JUOsP-UUavQHE1d9TpA5SDMN2EtBc=.634a55bd-f6e3-4ee2-900a-7c958529270e@github.com>

On Fri, 28 Mar 2025 08:56:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> SwingNodePlatformExitCrashTest hangs while running on wayland, we need to skip this test on wayland until https://bugs.openjdk.org/browse/JDK-8350009 is fixed.

The hang we are seeing on Wayland Linux when running on some systems is due to [JDK-8335468](https://bugs.openjdk.org/browse/JDK-8335468), which is fixed in AWT in JDK 24. So 

So the solution to [JDK-8350009](https://bugs.openjdk.org/browse/JDK-8350009), which is a test bug, will almost certainly be to disable the test on Wayland when running the test on JDK 23 (or earlier). Something like this, modifying the currently proposed Assumption so that it only skipped when running an older JDK:


        Assumptions.assumeTrue(!Util.isOnWayland() || Runtime.version().feature() >= 24);


Maybe it is better, then, to just fix  [JDK-8350009](https://bugs.openjdk.org/browse/JDK-8350009) with the revised Assumption as above.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1745#issuecomment-2766138118

From angorya at openjdk.org  Mon Mar 31 14:23:47 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 14:23:47 GMT
Subject: RFR: 8351047: TitledPane should handle titles that are resizable
 [v2]
In-Reply-To: <ditUVXWS-lvgiaOtQuB8yoAj039B2KEK8WUw_kMftqc=.39fb3b6a-c691-49bd-a13a-20be87adfc6b@github.com>
References: <VhqVuIpZvCg2LhyfnYRn80rhB7iHa2uEHED40VVi-2s=.f3093612-690a-4a72-b27f-b5ed02acfb0c@github.com>
 <ditUVXWS-lvgiaOtQuB8yoAj039B2KEK8WUw_kMftqc=.39fb3b6a-c691-49bd-a13a-20be87adfc6b@github.com>
Message-ID: <pO7NRqNgvUJbGFNfqsfmvQM40zUhwgeyoFKSlsOfZ8E=.8b6e44e2-c551-4e6a-826a-ce907349a561@github.com>

On Sat, 29 Mar 2025 09:10:51 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR will forward more Label calculations to LabeledSkinBase, as they are quite complex, especially when a Graphic is involved which is a full-fledged `Node`. More specifically, this solves issues with TitledPane when the graphic is resizable (ie. an HBox is placed as Graphic in the titled pane's title area).  Before, the calculations would only look at the preferred size of the graphic, and use these regardless of available space, even if the maximum size allowed for the graphic to be larger. After this fix, the more extensive LabeledSkinBase calculations are used.
>> 
>> This PR also simplifies the layout calculation.  Instead of manually calculating where the label should be positioned (according to alignment), this is left to `layoutLabelInArea` which will do this automatically when its provided with the available space for the label instead of the label's width.
>> 
>> See the ticket for a sample program; take a look at the graphic-only case where an HBox is used to put a label + gap + button as the graphic of the titled pane.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by angorya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1742#pullrequestreview-2729481721

From angorya at openjdk.org  Mon Mar 31 14:54:38 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 14:54:38 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <Sk3uNHNchvDUSwKWUgLVavslzQgE3WAN0OZ0ocn3mgE=.4a3cee3d-b576-434f-a876-556d188d2ae5@github.com>

On Fri, 28 Mar 2025 21:00:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> A possible improvement could be to output a data URL
>> 
>> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
>> 
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>
> tests/system/src/test/java/test/robot/javafx/scene/control/behavior/TextAreaBehaviorRobotTest.java line 40:
> 
>> 38:  * since the mapped functions require rendered text.
>> 39:  */
>> 40: @ExtendWith(ScreenCaptureTestWatcher.class)
> 
> A JUnit5 annotation seams like an easy way to mark our robot tests for capture. Are there any drawbacks with this approach?

I don't think so - it's a simple way to plug in into the junit5 framework.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021207520

From angorya at openjdk.org  Mon Mar 31 15:01:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 15:01:40 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>

On Fri, 28 Mar 2025 21:04:00 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> A possible improvement could be to output a data URL
>> 
>> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
>> 
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 47:
> 
>> 45:  * <p>
>> 46:  * This facility takes a screenshot of any failed test, then logs the base64-encoded screenshot
>> 47:  * to {@code stderr}.
> 
> This should not be on by default, but should be "opt in" on a System property. I recommend defining a gradle property to do this and map it to that System property, much like we do for "UNSTABLE_TEST" and others.

The intent is not to annotate each test, but rather to use this tool to debug the issues in an intermittently failing test.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021218682

From angorya at openjdk.org  Mon Mar 31 15:06:55 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 15:06:55 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <wTb8zmT-cYOoTpKkp6LHRDdHYyzy7tc1pMOyu3jpleo=.eecd2063-b2d9-4291-abab-d98b659bd9fc@github.com>

On Fri, 28 Mar 2025 21:07:21 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> A possible improvement could be to output a data URL
>> 
>> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
>> 
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 64:
> 
>> 62:  * <p>
>> 63:  * WARNING: using this utility may significantly increase the size of your logs!
>> 64:  * Make sure there is plenty of free disk space.
> 
> Given my earlier comment about this needing to be qualified by a system property, this comment should also go in `build.gradle` where the property is defined.

see the earlier comment about the intermittent tests

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021228036

From kcr at openjdk.org  Mon Mar 31 16:04:35 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 16:04:35 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
Message-ID: <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>

On Mon, 31 Mar 2025 14:58:11 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 47:
>> 
>>> 45:  * <p>
>>> 46:  * This facility takes a screenshot of any failed test, then logs the base64-encoded screenshot
>>> 47:  * to {@code stderr}.
>> 
>> This should not be on by default, but should be "opt in" on a System property. I recommend defining a gradle property to do this and map it to that System property, much like we do for "UNSTABLE_TEST" and others.
>
> The intent is not to annotate each test, but rather to use this tool to debug the issues in an intermittently failing test.

Hmm. That isn't what I thought we were doing. I thought the idea was to annotate most (if not all all) screen capture tests, qualified by a system property, enable that property in our CI test runs, so that when we do get intermittent failures, we'll be able to take a look at them.

We _could_ to what you propose, but in that case I wouldn't want _any_ tests annotated as part of this or any other PR. Once we have this annotation on any test in our repo, then my objection about not having it on by default needs to be addressed, at which point you might as well annotate more tests, since we have seen occasional failures on many of them.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021320825

From kcr at openjdk.org  Mon Mar 31 16:22:39 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 16:22:39 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v3]
In-Reply-To: <1fys35MLDad0FdF52ICk8KtGttyVf2DlLNIaJKP7uPg=.8c7ae286-5b8d-48ea-bc6d-836244576de0@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <eC2b9F1EKDlQKwBjhukF90sbI4ksaVhlXw4BsKYUYKI=.90d6b611-412c-4fc8-a2fb-445a7fb4cdc3@github.com>
 <bIULSAqVn74mPcT3Il2HQ2OhW_e3L9cfHcK94WTrBkM=.66f9df16-84e2-4979-8b75-57009ede4ad6@github.com>
 <of0OzcnjCK98ouVcF7eh0antA3HARGJz2Kk4U3m7Z5I=.f3f86181-0bfd-4ad3-adcb-8284c881b17f@github.com>
 <1fys35MLDad0FdF52ICk8KtGttyVf2DlLNIaJKP7uPg=.8c7ae286-5b8d-48ea-bc6d-836244576de0@github.com>
Message-ID: <kAVQkyBPBFLFlE-mfoWS5uDNVtRtE9aEalqrolWj_Xo=.95d60f18-cd07-467d-b483-cc3c1af742ee@github.com>

On Fri, 28 Mar 2025 05:58:19 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> > The docs on `canStartNestedEventLoop` describe its behavior already. I'm not sure what further information would be useful. Would it be enough to add a see also link?
> 
> The exception being thrown is a behavior of `enterNestedEventLoop()`, and should therefore be documented with this method (`@see` is not enough). While that is done now with the `@throws` javadoc tag, I think it wouldn't hurt to be more explicit about that; much in the same way as the javadoc summary already contains an explicit description of the preconditions of calling the method.

How about adding something like this, right after the other preconditions?


* There is a finite limit on the depth of the nested event loop stack. An exception will be thrown
*  if this limit is exceeded. Applications that want to avoid an exception can call
* {@link #canStartNestedEventLoop canStartNestedEventLoop} to see whether it is possible
* to start one.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1741#issuecomment-2766741097

From kcr at openjdk.org  Mon Mar 31 16:30:47 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 16:30:47 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <52smgs2IFoHbQO_NXhK9xbbxQbenQWX_xgA6tmZYc94=.ad68cbe5-0a09-4b07-b078-1ed50217675d@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <52smgs2IFoHbQO_NXhK9xbbxQbenQWX_xgA6tmZYc94=.ad68cbe5-0a09-4b07-b078-1ed50217675d@github.com>
Message-ID: <Iurt4IzYc517G4YLnyeaRp6zRDUa0wbrmapTrTC6rkw=.40cd25d1-ed51-4953-9f6c-15f10fd3daab@github.com>

On Fri, 28 Mar 2025 23:16:18 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> On a related note, where is it documented how to run manual tests?

It isn't documented anywhere. Nor are the tests wired up to the build. We have the following test sprint bug filed:

[JDK-8296441](https://bugs.openjdk.org/browse/JDK-8296441): Build and run manual tests from gradle

We might want to do that one first before implementing this one. Without some way from gradle, ant, or a shell script, it will be difficult to run any of the tests that start using this utility.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2766760597

From angorya at openjdk.org  Mon Mar 31 16:48:23 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 16:48:23 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <Zk2BSjP-gvEaAI0obsjGd2EyH6Y5qOPObAi6QczpsiY=.eafe235c-ddab-45c5-8cf3-b41626255e2f@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <Zk2BSjP-gvEaAI0obsjGd2EyH6Y5qOPObAi6QczpsiY=.eafe235c-ddab-45c5-8cf3-b41626255e2f@github.com>
Message-ID: <bSwFvo3zO7nRraoUMO7lxUl8xjnBMxiwH5xqlNvna_w=.662cc93f-17f2-4169-a498-cfa3240cb4c1@github.com>

On Fri, 28 Mar 2025 21:31:45 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 77:
>> 
>>> 75:     public void testFailed(ExtensionContext extensionContext, Throwable err) {
>>> 76:         err.printStackTrace();
>>> 77:         System.err.println(generateScreenshot("Screenshot:{", "}"));
>> 
>> When does the `testFailed` method run? After a failing `@Test` method that throws the exception? What if there is more than one failing test? Ideally what we want is something that runs after all failing tests, but before the `@AfterEach` method.
>
> Or... maybe we really do want to take a screen dump for each failing test in a test class.
> 
> Also, what happens if one of the lifecycle methods is the one that throws the error (e.g., `Before` `After`, etc)?

good question!  A quick test indicates that `@BeforeAll` and `@AfterAll` are treated as the framework errors and not handled by the watcher, but the failures in `@Test`, `@BeforeEach`, and `@AfterEach` are sent to the test watcher.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021388320

From angorya at openjdk.org  Mon Mar 31 16:54:13 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 16:54:13 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <6oHCnvpN9PEz8R_JZmPU4mgzzfIGR5AeBfzX-XKMNTw=.061632dd-30bd-4029-a296-2e7fe4537a6b@github.com>

On Fri, 28 Mar 2025 21:09:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
>> 
>> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
>> 
>> A possible improvement could be to output a data URL
>> 
>> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
>> 
>> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 67:
> 
>> 65:  */
>> 66: // TODO investigate having a hard-coded or programmable via property limit on the number of
>> 67: // captured screenshots.
> 
> I had the same thought. Given that each test runs in its own JVM, I can't think of a good way to do it other than recording information in a file in tests/system/build.

Exactly.  I don't have a good way, and I would rather not write to a file.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021394385

From kcr at openjdk.org  Mon Mar 31 17:04:17 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 17:04:17 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v8]
In-Reply-To: <sW4JEpN1Q8woljItgozxh2JlhyC1NQjSFsNjcEVK7jU=.d8f6ec8e-4dae-4859-9534-4e340a2ba9d6@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <sW4JEpN1Q8woljItgozxh2JlhyC1NQjSFsNjcEVK7jU=.d8f6ec8e-4dae-4859-9534-4e340a2ba9d6@github.com>
Message-ID: <8ENE-38HoRYs8QSs3d-RQ3zbPSc82--DMYGFoWjwtKQ=.86587ecd-dd80-4bc1-a120-b91e58188217@github.com>

On Fri, 28 Mar 2025 15:10:46 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer 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 nine additional commits since the last revision:
> 
>  - revert to original mime types
>  - Merge remote-tracking branch 'remotes/origin/master' into JDK-8281384
>  - readding flavors with changed mapping
>  - remove non unicode textformats
>  - format and unneeded var removed
>  - cleanup
>  - search NUL terminator in native code
>  - check both UTF16 bytes
>  - JDK-8281384: Random chars on paste from Windows clipboard

The latest version looks good to me. I tested it and it works as expected.

I left a suggestion and minor formatting comment. Will reapprove if you make changes.

modules/javafx.graphics/src/main/native-glass/win/GlassClipboard.cpp line 410:

> 408:                 jbyte *pos = me.getMem() + i;
> 409:                 if (*(pos) == 0 && *(pos + 1) == 0){
> 410:                     cdata = i;

Suggestion: Although the loop will terminate as currently coded, it might be clearer to add an explicit "break;" here.

Minor: add a space between the `)` and `{` on lines 407 and 409.

-------------

Marked as reviewed by kcr (Lead).

PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2729879366
PR Review Comment: https://git.openjdk.org/jfx/pull/1724#discussion_r2021379918

From angorya at openjdk.org  Mon Mar 31 17:07:09 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 17:07:09 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v2]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <0ahJGBdXoAXTX9sUU45mE7d4TIyKUWigCYlEXqpNDzg=.09e88029-37a2-4fdd-a551-461830fd680e@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> A possible improvement could be to output a data URL
> 
> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
> 
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)

Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:

 - testing: inject a failure
 - review comments

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/042b5838..c7bdcee7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=00-01

  Stats: 143 lines in 4 files changed: 6 ins; 134 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From angorya at openjdk.org  Mon Mar 31 17:07:10 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 17:07:10 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v2]
In-Reply-To: <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
 <W6i3URblcpspzWvt65Xdabwt-JKNMj3hTwudiugN1zU=.afe3cbb0-02b0-4791-a256-2b60961236f6@github.com>
 <v6Z5pWtUrvtNBBUdkZGZlkSmqCV_WTumuN7L2SIdZPY=.1a3606e4-d396-4c5f-a619-f2c0b267d0d0@github.com>
Message-ID: <rMoa3GU-CTt53qX-3pfBhgzPg3toFwkncJ2HCWXktZE=.04e226e8-8fb5-426c-beba-97c8df5ed329@github.com>

On Mon, 31 Mar 2025 16:01:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The intent is not to annotate each test, but rather to use this tool to debug the issues in an intermittently failing test.
>
> Hmm. That isn't what I thought we were doing. I thought the idea was to annotate most (if not all all) screen capture tests, qualified by a system property, enable that property in our CI test runs, so that when we do get intermittent failures, we'll be able to take a look at them.
> 
> We _could_ to what you propose, but in that case I wouldn't want _any_ tests annotated as part of this or any other PR. Once we have this annotation on any test in our repo, then my objection about not having it on by default needs to be addressed, at which point you might as well annotate more tests, since we have seen occasional failures on many of them.

There is more than one way to sk^H^H pet the cat.

We could use a property to disable (or rather, enable) the screenshots, and only enable the capture during the debugging session.  This will prevent us from catching those hard-to-reproduce intermittent tests that fail only occasionally.

The other concern is that in the case of some infrastructure misconfiguration (for example, a sudden loss of screen capture permission) would result in log file size explosion, and I don't think we have `tailwatch`-like facility to halt the test run when this happens.

I think the debug-only annotation is a meaningful compromise, but I would very much welcome other ideas.

(I am ok with removing the annotation from two tests that currently use it).

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021406569

From oschmidtmer at openjdk.org  Mon Mar 31 17:48:50 2025
From: oschmidtmer at openjdk.org (Oliver Schmidtmer)
Date: Mon, 31 Mar 2025 17:48:50 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v9]
In-Reply-To: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
Message-ID: <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>

> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
> 
> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
> If this should be added as a unit test, I'm open for advice how to do that.

Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:

  explicit break

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1724/files
  - new: https://git.openjdk.org/jfx/pull/1724/files/3a4eb33a..337a67fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=08
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1724&range=07-08

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jfx/pull/1724.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1724/head:pull/1724

PR: https://git.openjdk.org/jfx/pull/1724

From mfox at openjdk.org  Mon Mar 31 17:49:59 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 31 Mar 2025 17:49:59 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v7]
In-Reply-To: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
Message-ID: <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>

> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
> 
> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
> 
> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.

Martin Fox has updated the pull request incrementally with one additional commit since the last revision:

  Added description of the new nested event loop limit.

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1741/files
  - new: https://git.openjdk.org/jfx/pull/1741/files/99d2878f..74b8034f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=06
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1741&range=05-06

  Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jfx/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1741/head:pull/1741

PR: https://git.openjdk.org/jfx/pull/1741

From mfox at openjdk.org  Mon Mar 31 17:56:06 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 31 Mar 2025 17:56:06 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
 <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>
Message-ID: <omeS_mnF-w3ojZgmkw20Lx0t-ERu_dmxKB8NGxm128w=.9b9e5712-8b16-4760-852e-0e5e2884c463@github.com>

On Fri, 28 Mar 2025 23:06:47 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> The following command line expectedly fails because it can't find `com.oracle.util.testing.ManualTestWindow`:
> 
> ```
> java --module-path=build/sdk/lib --add-modules=javafx.controls ./tests/manual/text/EmojiTest.java
> ```

When I was working on my manual tests @tsayao provided a useful tip. If you change the`launch(args)` call in EmojiTest.java to `launch(EmojiTest.class, args)` it's easy to run it from the command line like so:

`java @build/run.args tests/manual/text/EmojiTest.java`

It would be nice if all the manual tests did this, it makes them a lot easier to interact with.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2766972605

From angorya at openjdk.org  Mon Mar 31 18:08:18 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 18:08:18 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v7]
In-Reply-To: <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
Message-ID: <trzZjpZiUdJk3ypr9_EvUi1Q6Bxm7aJYuGyNhclQ6LE=.92e1e451-e7ac-4c1b-b92e-ece572ea9d07@github.com>

On Mon, 31 Mar 2025 17:49:59 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added description of the new nested event loop limit.

Marked as reviewed by angorya (Reviewer).

modules/javafx.graphics/src/main/java/javafx/application/Platform.java line 296:

> 294:      * {@link #canStartNestedEventLoop canStartNestedEventLoop} to check
> 295:      * whether it is possible to start one.
> 296:      *

+1

-------------

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2730131518
PR Review Comment: https://git.openjdk.org/jfx/pull/1741#discussion_r2021535222

From kcr at openjdk.org  Mon Mar 31 18:11:43 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 18:11:43 GMT
Subject: RFR: 8281384: Random chars on paste from Windows clipboard [v9]
In-Reply-To: <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
References: <LvJixztC_ZNQwr0Xl6sojxnSF-xh0B3R_n3R949I8C8=.3acac72f-ca46-4fec-9885-3969de6870a9@github.com>
 <6moTmxOBtB4kYIrBSM6cKcvKkTQzUZNis6PH-zO_t_M=.161ed456-b29d-472c-831a-da4247b4e4ea@github.com>
Message-ID: <RW48FSptvINk-Tb1En6cQaiLXIpIWkBH-1FD3_t0jPE=.6164a86b-601c-47bc-92fe-92c38befd4a6@github.com>

On Mon, 31 Mar 2025 17:48:50 GMT, Oliver Schmidtmer <oschmidtmer at openjdk.org> wrote:

>> Windows programs may reuse a clipboard buffer that is larger than the new content. In this case de NUL terminator is not at the end of the buffer, but within it. 
>> The current implementation copys the whole buffer into a text field, including the NUL terminator and the remaining chars.
>> 
>> The JIRA ticket contains a JNA based sample program, which prefills the buffer for demonstrating this issue.
>> If this should be added as a unit test, I'm open for advice how to do that.
>
> Oliver Schmidtmer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   explicit break

Marked as reviewed by kcr (Lead).

-------------

PR Review: https://git.openjdk.org/jfx/pull/1724#pullrequestreview-2730141862

From angorya at openjdk.org  Mon Mar 31 18:22:12 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 18:22:12 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v2]
In-Reply-To: <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
 <qDP0hIdl0xmGt47bTS8B0AZKLGcSN3pxPWUJo1vmqCQ=.9301440a-6a4a-4cb2-a843-a2914682f3df@github.com>
Message-ID: <7ENT7-p-Dm5nH-n_ApKrzhgqVUiOmr02ubUZvXcj-rA=.0f6ce2a6-4be0-4658-aae4-67c4d0f6e988@github.com>

On Fri, 28 Mar 2025 21:10:46 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Goryachev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - testing: inject a failure
>>  - review comments
>
> tests/system/src/test/java/test/util/ScreenCaptureTestWatcher.java line 71:
> 
>> 69:     @Override
>> 70:     public void testAborted(ExtensionContext extensionContext, Throwable err) {
>> 71:         err.printStackTrace();
> 
> Is this needed or is it just for debugging? We already get a stack trace when a test fails, so it might be redundant.

Good point - it's not needed.  The junit framework outputs a truncated stack trace which should be sufficient:


TextAreaBehaviorRobotTest > fail() FAILED
    java.lang.Error
        at test.robot.javafx.scene.control.behavior.TextAreaBehaviorRobotTest.fail(TextAreaBehaviorRobotTest.java:49)

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1746#discussion_r2021561824

From angorya at openjdk.org  Mon Mar 31 18:30:40 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 18:30:40 GMT
Subject: RFR: 8319555: [TestBug] Utility for creating instruction window
 for manual tests
In-Reply-To: <omeS_mnF-w3ojZgmkw20Lx0t-ERu_dmxKB8NGxm128w=.9b9e5712-8b16-4760-852e-0e5e2884c463@github.com>
References: <t57zeYPEQbapfqSW9CwHWjTRqXCTWwO0Kq25r9AfP_I=.90a718e0-a50b-4a10-9fae-19efbee4b1ba@github.com>
 <31yf5mJD12V39DQxj-2UclRnKHf5INKMRKRySQtDsJc=.7c561e2f-ddcd-49ef-824a-b04d1bb80264@github.com>
 <aMccVsXfGF7ykv7TZCzBzDfn9fkzAVe5IYsr5Dsrhx8=.f00272fb-a183-479b-a2c7-0a5a5a3f71f7@github.com>
 <omeS_mnF-w3ojZgmkw20Lx0t-ERu_dmxKB8NGxm128w=.9b9e5712-8b16-4760-852e-0e5e2884c463@github.com>
Message-ID: <Qb30PCbXciWeMPT5vRRyYrN92uyPmYW3hctqNjGQYw0=.d46689f0-b49b-42ee-9e4a-4d6b78c43326@github.com>

On Mon, 31 Mar 2025 17:53:01 GMT, Martin Fox <mfox at openjdk.org> wrote:

> It would be nice if all the manual tests did this

Good idea.  I might need some help with this though - this command line 

`java @build/testrun.args ./tests/manual/text/EmojiTest.java` fails because it cannot find


./tests/manual/text/EmojiTest.java:32: error: package com.oracle.util.testing does not exist
import com.oracle.util.testing.ManualTestWindow;
                              ^
./tests/manual/text/EmojiTest.java:34: error: cannot find symbol
public class EmojiTest extends ManualTestWindow {
                               ^
  symbol: class ManualTestWindow
./tests/manual/text/EmojiTest.java:36: error: cannot find symbol
        launch(args);
        ^
  symbol:   method launch(String[])
  location: class EmojiTest
./tests/manual/text/EmojiTest.java:62: error: method does not override or implement a method from a supertype
    @Override
    ^
4 errors



I do have the `ManualTestWindow.class` in `tests/manual/util/bin/` but I think it's the Eclipse build directory.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1747#issuecomment-2767061592

From mfox at openjdk.org  Mon Mar 31 18:34:32 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 31 Mar 2025 18:34:32 GMT
Subject: RFR: 8352999: [macOS] Conditional behavior by directly querying the
 Objective-C call stack
Message-ID: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>

Before a window is maximized glass records its existing size and location. This rectangle is stored in native screen coordinates. Compared to Java screen coordinates native coordinates are flipped along the Y axis.

When the window is un-maximized that native rectangle is passed to a routine that normally takes Java screen coordinates. To determine whether the rectangle is flipped or not the code inspects the Objective-C stack to figure out which routine called it.

At the risk of re-writing working code this PR takes a more conventional approach to the problem.

I?ve also re-enabled the related system test. I had to increase the animation delay to get it to pass on the Mac. 400 milliseconds is enough but 500 gives us some headroom.

-------------

Commit messages:
 - Removed code that was building an NSRect verbatim from an existing NSRect
 - No longer querying Objective-C stack to determine window frame coordinate system

Changes: https://git.openjdk.org/jfx/pull/1749/files
  Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1749&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352999
  Stats: 23 lines in 2 files changed: 1 ins; 19 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1749.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1749/head:pull/1749

PR: https://git.openjdk.org/jfx/pull/1749

From kcr at openjdk.org  Mon Mar 31 18:34:45 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Mon, 31 Mar 2025 18:34:45 GMT
Subject: RFR: 8351733: Crash when creating too many nested event loops [v7]
In-Reply-To: <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
References: <CXju8shX5EuOAAaPOav7xcBFhsRxv4qnxMktQ877zVg=.50154238-1b93-41b1-8400-159a5000f94e@github.com>
 <42VwnlUL9gTsLrjc5spYh7KulNsAkp2qAR-UW5Nlps8=.dfb81bcc-cc2a-4d55-9554-e9fd53b62f51@github.com>
Message-ID: <Uh-jaG-1kIRCrHEKLE4XORrjzcqm0aB0H9IyvZyHv6k=.cb1917a2-3a3d-41f4-8d83-9e228c16a5d9@github.com>

On Mon, 31 Mar 2025 17:49:59 GMT, Martin Fox <mfox at openjdk.org> wrote:

>> There is an undocumented limit on nesting calls to CFRunLoopRun (or the equivalent wrapper NSRunLoop methods). When the limit is hit the OS terminates the Java app. The situation arises when a JavaFX app creates too many nested event loops from within  Platform.runLater runnables.
>> 
>> This PR doesn't change the limit (which is 250+ nested loops) but it does throw an exception just before the limit is reached so a JavaFX developer will get a useful Java stack trace instead of an OS crash log.
>> 
>> On the Mac the nested event loop has two stages: first we ask the run loop to run, then we pull an event out and process it. A Platform.runLater runnable is executed in the first stage so if the runnable starts a new nested event loop the system will re-enter CFRunLoopRun. The same isn't true if an input event handler starts a new nested event loop; at that point we're in stage two and are past the call to CFRunLoopRun.
>
> Martin Fox has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added description of the new nested event loop limit.

Latest version looks good. I've fired off a CI headful test build and will report back once it completes and I finish my testing.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1741#pullrequestreview-2730197306

From angorya at openjdk.org  Mon Mar 31 18:35:03 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 18:35:03 GMT
Subject: RFR: 8328716: [TestBug] Screen capturing utility for failed tests
 [v3]
In-Reply-To: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
References: <UuDPTqScYrF_1m7h6g_tSyxLfRH56AHyfjiafQBLrbo=.21a778f3-9356-46a5-a252-e3a2985e4135@github.com>
Message-ID: <OQ2S6cYNrQGoLP9c7ZB2_4zBi08ET_WBw0SLX6b8sHI=.099b388e-cc36-400c-b057-e4ae47dff034@github.com>

> Introduce a facility, in the form of JUnit5 annotation, to allow for capturing a desktop screenshot of a failed test.
> 
> The primary intent is to be able to debug an intermittent test case, rather than wholesale addition of the new annotation to all the tests.
> 
> A possible improvement could be to output a data URL
> 
> `data:image/png;base64,iVBORw0KGgoAAAANSUhEU...`
> 
> so it can be rendered in Safari (Chrome truncates the image possibly due to following a url length limit)

Andy Goryachev has updated the pull request incrementally with one additional commit since the last revision:

  data url

-------------

Changes:
  - all: https://git.openjdk.org/jfx/pull/1746/files
  - new: https://git.openjdk.org/jfx/pull/1746/files/c7bdcee7..5e184b0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=02
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1746&range=01-02

  Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jfx/pull/1746.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1746/head:pull/1746

PR: https://git.openjdk.org/jfx/pull/1746

From angorya at openjdk.org  Mon Mar 31 20:44:41 2025
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 31 Mar 2025 20:44:41 GMT
Subject: RFR: 8352999: [macOS] Conditional behavior by directly querying
 the Objective-C call stack
In-Reply-To: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>
References: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>
Message-ID: <8g3lBZSn1x2rVrnt1UM7W9C1W_mMwYFW8hfVuPUKSjg=.d078ac6f-4bab-4f12-b493-2c2e177226a8@github.com>

On Mon, 31 Mar 2025 18:29:21 GMT, Martin Fox <mfox at openjdk.org> wrote:

> Before a window is maximized glass records its existing size and location. This rectangle is stored in native screen coordinates. Compared to Java screen coordinates native coordinates are flipped along the Y axis.
> 
> When the window is un-maximized that native rectangle is passed to a routine that normally takes Java screen coordinates. To determine whether the rectangle is flipped or not the code inspects the Objective-C stack to figure out which routine called it.
> 
> At the risk of re-writing working code this PR takes a more conventional approach to the problem.
> 
> I?ve also re-enabled the related system test. I had to increase the animation delay to get it to pass on the Mac. 400 milliseconds is enough but 500 gives us some headroom.

just curious: could this have any relevance to https://bugs.openjdk.org/browse/JDK-8353314 ?

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1749#issuecomment-2767350341

From mfox at openjdk.org  Mon Mar 31 21:13:41 2025
From: mfox at openjdk.org (Martin Fox)
Date: Mon, 31 Mar 2025 21:13:41 GMT
Subject: RFR: 8352999: [macOS] Conditional behavior by directly querying
 the Objective-C call stack
In-Reply-To: <8g3lBZSn1x2rVrnt1UM7W9C1W_mMwYFW8hfVuPUKSjg=.d078ac6f-4bab-4f12-b493-2c2e177226a8@github.com>
References: <zbgaETsVLGXADa6CiIUh5vxMQwL0V3538SgjN_bqeqg=.f047ecab-0d6b-4e9b-aa6b-bc473e9dba25@github.com>
 <8g3lBZSn1x2rVrnt1UM7W9C1W_mMwYFW8hfVuPUKSjg=.d078ac6f-4bab-4f12-b493-2c2e177226a8@github.com>
Message-ID: <KkvaU684NiBjbinZZNOu3SiMS1_7ek89hgXy3bQHqVQ=.b1f0ec3c-f76a-447e-849e-0e15318203f1@github.com>

On Mon, 31 Mar 2025 20:41:10 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> just curious: could this have any relevance to https://bugs.openjdk.org/browse/JDK-8353314 ?

No, I can still reproduce that bug with this PR. Something else is going on.

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1749#issuecomment-2767407134