From abhinay_agarwal at live.com  Fri Oct  1 07:05:25 2021
From: abhinay_agarwal at live.com (Abhinay Agarwal)
Date: Fri, 1 Oct 2021 07:05:25 +0000
Subject: Enhancements for JavaFX 18
In-Reply-To: <c65a8300-a99a-0903-7226-d411bc16d18a@oracle.com>
References: <c65a8300-a99a-0903-7226-d411bc16d18a@oracle.com>
Message-ID: <d8526a52-ca60-dce7-cbad-3159a5a21476@live.com>

Hi,

I recently worked on removing a few left-over Traversal engine usage in ControlsFX [1].

It can be tricky, sometimes impossible, to get the traversal part right in a custom control which can be done using 2 lines if Traversal API was present [2].

This made me thinking if there is a scope of adding the Traversal engine API to JavaFX. Most of the heavy lifting was already done by Jonathan in JDK-8091673 [3].

-- Abhinay

[1] https://github.com/controlsfx/controlsfx/pull/1395
[2] https://github.com/controlsfx/controlsfx/pull/1395/files#r712829957
[3] https://bugs.openjdk.java.net/browse/JDK-8091673

On 30/07/21 6:26 pm, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to proceed)

* Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread.

-- Kevin



From hjohn at xs4all.nl  Fri Oct  1 09:31:52 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Fri, 1 Oct 2021 11:31:52 +0200
Subject: Need some direction: JDK-8089024
Message-ID: <134aca2a-d95d-4318-2595-f63f618dadb2@xs4all.nl>

Please see:

   https://bugs.openjdk.java.net/browse/JDK-8089024

This is a bug which seems to apply transparency twice when a Node has a 
clip set.  I managed to create a small test program that shows the 
problem very clearly, see this image (on Windows):

   https://pasteboard.co/djKKvPVsCfYC.png

Note that the two bottom rows should look identical, but they don't.

If I could get some direction where to look for this problem I might be 
able to solve it.

--John

From arapte at openjdk.java.net  Fri Oct  1 10:34:49 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 1 Oct 2021 10:34:49 GMT
Subject: RFR: 8214158: Implement HostServices.showDocument on macOS
 without calling AWT [v5]
In-Reply-To: <TxzrKR4SNVXnYXL4FqvcPpqrLzLUmX2028n1q4GuscE=.db3867b4-72e1-4b6f-8c45-26cb2c2d4b99@github.com>
References: <r-ChNMxfDiOMRKNuShq4JpJW6LBLobVlq_-kROx2LyY=.1fd28cb9-0de7-430e-ba7e-807d6ad4f0b0@github.com>
 <TxzrKR4SNVXnYXL4FqvcPpqrLzLUmX2028n1q4GuscE=.db3867b4-72e1-4b6f-8c45-26cb2c2d4b99@github.com>
Message-ID: <wqFhjwDq1cSR4DUjbkKvDmudrom0TRMkEnBIBjkXCYg=.a21347be-3063-4db3-b628-dc44d536d82c@github.com>

On Thu, 30 Sep 2021 13:24:26 GMT, Michael Paus <mpaus at openjdk.org> wrote:

>> Fixes the issue by using the "open" command as discussed before.
>> See: https://bugs.openjdk.java.net/browse/JDK-8214158
>
> Michael Paus has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed two minor formatting issues

Looks good. Verified on Mac and Windows.

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

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/634

From aghaisas at openjdk.java.net  Fri Oct  1 11:21:32 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 1 Oct 2021 11:21:32 GMT
Subject: RFR: 8188026: TextFieldXXCell: NPE on calling startEdit [v5]
In-Reply-To: <xZByyd75BlSaV-6yarffGeZFt36kBHBDGoUpILGnLeg=.cd95eb11-ba2c-449a-a0fc-a668da828d4a@github.com>
References: <qnBbdIneY2MbWOkU1bIt8cR6xjG7DkpxtrdfbiiT-bI=.e8572c73-4a15-4ab1-a275-7fddf6529443@github.com>
 <xZByyd75BlSaV-6yarffGeZFt36kBHBDGoUpILGnLeg=.cd95eb11-ba2c-449a-a0fc-a668da828d4a@github.com>
Message-ID: <clTlMvpUt2kc8wD9RMUiGqX5K-LTjdN77L1QiTqkokM=.dcd11cbc-8550-4f47-9756-31ecc4a86c51@github.com>

On Sun, 19 Sep 2021 11:52:55 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR sets an unified logic to every **startEdit()** method of all Cell implementations.
>> So startEdit() is always doing the same now:
>> 
>> `super.startEdit();`
>> `if (!isEditing()) {
>> return;
>> }` 
>> 
>> This will prevent a NPE while also being cleaner (no more double checks)
>> The commits are splitted into 4 base commits:
>> - First commit changes the startEdit() for TableCell implementations (8 files)
>> - Second commit changes the startEdit() for TreeTableCell implementations (7 files)
>> - Third commit changes the startEdit() for ListCell implementations (7 files)
>> - Fourth commit changes the startEdit() for TreeCell implementations (7 files)
>> 
>> While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong.
>> In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set.
>> 
>> I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042
>> The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe.
>> 
>> ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~
>> Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295
>
> Marius Hanl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments
>   
>   - cell is supplied in setup() method
>   - treeItem = null guard is done before calling startEdit()
>   - Added checks for the cell graphic

Marked as reviewed by aghaisas (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/569

From mpaus at openjdk.java.net  Fri Oct  1 11:59:35 2021
From: mpaus at openjdk.java.net (Michael Paus)
Date: Fri, 1 Oct 2021 11:59:35 GMT
Subject: Integrated: 8214158: Implement HostServices.showDocument on macOS
 without calling AWT
In-Reply-To: <r-ChNMxfDiOMRKNuShq4JpJW6LBLobVlq_-kROx2LyY=.1fd28cb9-0de7-430e-ba7e-807d6ad4f0b0@github.com>
References: <r-ChNMxfDiOMRKNuShq4JpJW6LBLobVlq_-kROx2LyY=.1fd28cb9-0de7-430e-ba7e-807d6ad4f0b0@github.com>
Message-ID: <aM1Dhh8aSq-ojzDa71HBv0KJX5QuaNaPPvcewfgehyY=.29c90868-8be4-4f63-a51d-a5803a0ef24d@github.com>

On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus <mpaus at openjdk.org> wrote:

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

This pull request has now been integrated.

Changeset: f3c72b93
Author:    Michael Paus <mpaus at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/f3c72b936b5c6c36eed022855d34570b1b9d3597
Stats:     112 lines in 5 files changed: 110 ins; 1 del; 1 mod

8214158: Implement HostServices.showDocument on macOS without calling AWT

Reviewed-by: kcr, arapte

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

PR: https://git.openjdk.java.net/jfx/pull/634

From mhanl at openjdk.java.net  Fri Oct  1 12:31:36 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 1 Oct 2021 12:31:36 GMT
Subject: Integrated: 8188026: TextFieldXXCell: NPE on calling startEdit
In-Reply-To: <qnBbdIneY2MbWOkU1bIt8cR6xjG7DkpxtrdfbiiT-bI=.e8572c73-4a15-4ab1-a275-7fddf6529443@github.com>
References: <qnBbdIneY2MbWOkU1bIt8cR6xjG7DkpxtrdfbiiT-bI=.e8572c73-4a15-4ab1-a275-7fddf6529443@github.com>
Message-ID: <c0iYVCsh-AeJGm1uLqxgK0iHkgS7pQ8tSuVUpmbPZ-4=.10aa007d-2c56-41ff-b4bf-0d2419e9aeb4@github.com>

On Wed, 7 Jul 2021 22:33:07 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR sets an unified logic to every **startEdit()** method of all Cell implementations.
> So startEdit() is always doing the same now:
> 
> `super.startEdit();`
> `if (!isEditing()) {
> return;
> }` 
> 
> This will prevent a NPE while also being cleaner (no more double checks)
> The commits are splitted into 4 base commits:
> - First commit changes the startEdit() for TableCell implementations (8 files)
> - Second commit changes the startEdit() for TreeTableCell implementations (7 files)
> - Third commit changes the startEdit() for ListCell implementations (7 files)
> - Fourth commit changes the startEdit() for TreeCell implementations (7 files)
> 
> While writing tests, I found out that the CheckBoxListCell and the CheckBoxTreeCell don't disable their CheckBox, which is wrong.
> In CheckBoxTableCell and CheckBoxTreeTableCell the CheckBox is disabled, but they don't check their dependencies e.g. TableColumn for null, leading to a NPE if not set.
> 
> I wrote a follow-up and assigned it to myself: https://bugs.openjdk.java.net/browse/JDK-8270042
> The aim of this should be, that all 4 CheckBox...Cells have a proper CheckBox disablement while also being nullsafe.
> 
> ~Note 1: I removed the tests in TableCellTest added in https://github.com/openjdk/jfx/pull/529 in favor of the new parameterized TableCellStartEditTest~
> Note 2: This also fixes https://bugs.openjdk.java.net/browse/JDK-8268295

This pull request has now been integrated.

Changeset: 64aa9263
Author:    Marius Hanl <mhanl at openjdk.org>
Committer: Jeanette Winzenburg <fastegal at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/64aa92631fa5aad9293553e8dd174eab647de2f3
Stats:     934 lines in 28 files changed: 625 ins; 257 del; 52 mod

8188026: TextFieldXXCell: NPE on calling startEdit
8268295: Tree- and TableCell sub implementations should respect the row editability

Reviewed-by: fastegal, aghaisas

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

PR: https://git.openjdk.java.net/jfx/pull/569

From mhanl at openjdk.java.net  Fri Oct  1 13:22:37 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 1 Oct 2021 13:22:37 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit
In-Reply-To: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
Message-ID: <mB2VmKthLDPLXsBC7Rwd6IIfze7vm_JMmN0-VXPP6_o=.bffdca1a-0665-4bfa-aa5b-6bc1a70887ec@github.com>

On Thu, 30 Sep 2021 12:00:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
> 
> - must not fire editStart event
> - must not update control's editing location
> 
> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
> 
> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.

Change looks good, I just left some comments on the tests. :)

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 860:

> 858:         cell.updateListView(list);
> 859:         cell.updateIndex(list.getItems().size());
> 860:         List<EditEvent> events = new ArrayList<>();

Very minor: You can use EditEvent<Object> here so you don't use the raw generic (and also on the other locations). But I guess that's just syntax sugar.

modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellTest.java line 874:

> 872:         cell.startEdit();
> 873:         assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
> 874:         assertEquals("list editing location must not be updated", - 1, list.getEditingIndex());

`-1` would look better here (without the space inbetween) given the fact this is not a mathematical context

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 726:

> 724:          int editingRow = table.getItems().size();
> 725:          cell.updateIndex(editingRow);
> 726:          List<CellEditEvent> events = new ArrayList<>();

`events` is effectively unused here, maybe you forgot the assert here?

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 870:

> 868:         cell.startEdit();
> 869:         assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
> 870:         assertEquals("editing location", null, tree.getEditingItem());

Minor: This can be replaced with `assertNull`, which would also be a bit more readable :)

modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeTableCellTest.java line 1051:

> 1049:          cell.startEdit();
> 1050:          assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
> 1051:          assertEquals("editing location", null, tree.getEditingCell());

Minor: This can be replaced with `assertNull`. :)

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

PR: https://git.openjdk.java.net/jfx/pull/636

From fastegal at openjdk.java.net  Fri Oct  1 14:25:44 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 1 Oct 2021 14:25:44 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit
In-Reply-To: <mB2VmKthLDPLXsBC7Rwd6IIfze7vm_JMmN0-VXPP6_o=.bffdca1a-0665-4bfa-aa5b-6bc1a70887ec@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
 <mB2VmKthLDPLXsBC7Rwd6IIfze7vm_JMmN0-VXPP6_o=.bffdca1a-0665-4bfa-aa5b-6bc1a70887ec@github.com>
Message-ID: <OrOSKYPcgSpfDnmqhRIPgITM05J2XWGsIsflxy4JDNQ=.31499c20-31ae-4aeb-b573-002aeb09c7fa@github.com>

On Fri, 1 Oct 2021 13:10:29 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
>> 
>> - must not fire editStart event
>> - must not update control's editing location
>> 
>> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
>> 
>> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 726:
> 
>> 724:          int editingRow = table.getItems().size();
>> 725:          cell.updateIndex(editingRow);
>> 726:          List<CellEditEvent> events = new ArrayList<>();
> 
> `events` is effectively unused here, maybe you forgot the assert here?

actually, no:  forgot to removed the unused list ;) Good catch!

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

PR: https://git.openjdk.java.net/jfx/pull/636

From mariushanl at web.de  Fri Oct  1 14:26:43 2021
From: mariushanl at web.de (Marius Hanl)
Date: Fri, 1 Oct 2021 16:26:43 +0200
Subject: Aw: Re: JavaFX snapping and scale
In-Reply-To: <f5438258-4e87-21a2-f933-59dfffd970c8@oracle.com>
References: <trinity-1d1ef66a-d9a6-4ae5-9902-54db08908161-1632735699982@3c-app-webde-bap32>
 <f5438258-4e87-21a2-f933-59dfffd970c8@oracle.com>
Message-ID: <trinity-2cc660d2-2623-4be5-899c-655e3da751e1-1633098403049@3c-app-webde-bap09>

   Thanks for your answer.

   Then one more question: How is a non-integer value rendered then?
   Say we have snapped x value of 10.4 (scale 1.25). As we can just render
   on a whole pixel, what will happen?

   - Marius


   Gesendet: Dienstag, 28. September 2021 um 01:57 Uhr
   Von: "Kevin Rushforth" <kevin.rushforth at oracle.com>
   An: openjfx-dev at openjdk.java.net
   Betreff: Re: JavaFX snapping and scale
   The basic idea behind snapping to pixel boundaries (which is optional,
   but on by default) is that 2D primitives will look more crisp if they
   are rendered on whole pixel boundaries. When there is no HiDPI
   involved,
   the operation of snapping to a pixel boundary can be done with a simple
   floor, round, or ceil operation (depending on what you are snapping).
   When there is a HIDPI scale involved, the value in user space needs to
   be chosen such that the transformed value ends up on a pixel boundary.
   That's why you will see snapped values that aren't on integer
   boundaries
   when the HiDPI scale is, say 1.25.
   In the case you ran into, the problem might be that the snapping isn't
   happening in the right place in the computation. Also, it seems quite
   possible that the clipping isn't being calculated correctly with
   respect
   to pixel snapping.
   You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2]
   for a recent example of a HiDPI bug affecting ScrollPane that was
   fixed.
   There are a couple of follow-on issues that came out of that issue,
   although I suspect they aren't relevant to the bug you are looking at.
   -- Kevin
   [1] [1]https://bugs.openjdk.java.net/browse/JDK-8211294
   [2] [2]https://github.com/openjdk/jfx/pull/308
   On 9/27/2021 2:41 AM, Marius Hanl wrote:
   > I recently tried to fix "TableView: visual glitch at borders on
   > horizontal scrolling".
   > Ticket: [1][3]https://bugs.openjdk.java.net/browse/JDK-8218745
   > PR: [2][4]https://github.com/openjdk/jfx/pull/630
   >
   > As also written in the PR I have problems understanding the
   > snapping/scaling of JavaFX.
   > Here in short what I found out:
   > - Snapping fixed the issue for a scale of 1 or 2, but not for a scale
   > like 1.25 or 1.5
   > --- Also VirtualFlow is the only occurence where we set the layoutX
   of
   > a clip (might be the problem?)
   > - This visual glitch only happens sometimes when the x value is a
   > decimal number, e.g. 12.66 (never when it's a round number like 13)
   > - Math.round(..) or a cast to int fixed this (for all scales), but is
   > probably not the correct solution or maybe only fixing a symptom here
   >
   > Which leads to my question where may some of you can help me:
   > - How does JavaFX renders a node when e.g. x is a decimal number? How
   > many pixel are used then?
   > - And does a decimal number make sense (Why we e.g. don't round the
   > value), which looks like it works fine and doesn't result in visual
   > glitches
   >
   > Also information/insights about fixes made in the past which relates
   > with this are welcome.
   > I saw that there were quite some issues with a scale other then 1 in
   > the past.
   >
   > Note: If the result is that everything works as expected chances are
   > there might a generic problem with snapping/layout/rendering
   somewhere
   > then.
   > Any information are welcome and feel free to also have a look at the
   > PR.
   >
   > -- Marius
   >
   > References
   >
   > 1. [5]https://bugs.openjdk.java.net/browse/JDK-8218745
   > 2. [6]https://github.com/openjdk/jfx/pull/630

References

   1. https://bugs.openjdk.java.net/browse/JDK-8211294
   2. https://github.com/openjdk/jfx/pull/308
   3. https://bugs.openjdk.java.net/browse/JDK-8218745
   4. https://github.com/openjdk/jfx/pull/630
   5. https://bugs.openjdk.java.net/browse/JDK-8218745
   6. https://github.com/openjdk/jfx/pull/630

From fastegal at openjdk.java.net  Fri Oct  1 14:29:29 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 1 Oct 2021 14:29:29 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit
In-Reply-To: <mB2VmKthLDPLXsBC7Rwd6IIfze7vm_JMmN0-VXPP6_o=.bffdca1a-0665-4bfa-aa5b-6bc1a70887ec@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
 <mB2VmKthLDPLXsBC7Rwd6IIfze7vm_JMmN0-VXPP6_o=.bffdca1a-0665-4bfa-aa5b-6bc1a70887ec@github.com>
Message-ID: <TovcDxj0BTYUcs59FITneGc93T5IHWbU2DXnQWBV3EA=.69675d36-ccf7-46a7-8caf-066f62194c3e@github.com>

On Fri, 1 Oct 2021 13:11:21 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
>> 
>> - must not fire editStart event
>> - must not update control's editing location
>> 
>> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
>> 
>> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeCellTest.java line 870:
> 
>> 868:         cell.startEdit();
>> 869:         assertFalse("sanity: off-range cell must not be editing", cell.isEditing());
>> 870:         assertEquals("editing location", null, tree.getEditingItem());
> 
> Minor: This can be replaced with `assertNull`, which would also be a bit more readable :)

haha .. left-over from c&p (of ListCellTest ;)

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

PR: https://git.openjdk.java.net/jfx/pull/636

From jhendrikx at openjdk.java.net  Fri Oct  1 14:47:41 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Fri, 1 Oct 2021 14:47:41 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
Message-ID: <I8CMHKcuf1dH0hlaDhPRkREzre8Ukats_n1vkZmMfIA=.b27f3869-2417-4412-80a3-6f5f1addd9f9@github.com>

On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez <github.com+6702882+dannygonzalez at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8185886
>> 
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed.
>> 
>> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews.
>> 
>> This may alleviate some of the issues seen here:
>> 
>> TableView has a horrific performance with many columns #409
>> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033
>> 
>> JDK-8088394 : Huge memory consumption in TableView with too many columns
>> JDK-8166956: JavaFX TreeTableView slow scroll performance
>> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction
>> 
>> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html
>
> dannygonzalez has updated the pull request incrementally.

I think it is also important to check if this is still an issue.

A PR which reduces the amount of listeners on Scene/Window was 
integrated in JavaFX 17: https://github.com/openjdk/jfx/pull/185

Are you experiencing problems still under 17?

I think PR 108 is addressing symptoms of a problem but not the root 
cause -- is it ever useful to have >10000 listeners on a single property 
which would warrant the use of Sets?  PR 185 solved this by not 
registering a listener for each Node on the Scene and Window, and there 
was some confirmation from the OP that this also addressed the issue, 
see here: https://github.com/openjdk/jfx/pull/108#issuecomment-615125904

--John

On 01/10/2021 13:27, John Nader wrote:
> This change is very near completion. According to @yososs
> <https://github.com/yososs>, what remains is to split the work into two
> separate PRs. The first PR must contain the updated test covering
> additional cases to ensure backwards compatibility. The second should
> contain the performance enhancement changes. This will allow the tests
> to be merged into master first, to ensure the behavior is maintained
> before and after the performance enhancement.
>
> I see that @dannygonzalez <https://github.com/dannygonzalez> has not
> been able to continue this work. If possible and appropriate, I would
> like to finish this work. I have already setup a build environment and
> have verified that the updated tests alone pass when integrated with the
> master branch and have 100% coverage of the modified class.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/openjdk/jfx/pull/108#issuecomment-932146935>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHTETIDTFZAQSKBVUFO3BLUEWLI7ANCNFSM4KQ7YBNA>.
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>

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

PR: https://git.openjdk.java.net/jfx/pull/108

From fastegal at openjdk.java.net  Fri Oct  1 14:59:02 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 1 Oct 2021 14:59:02 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit [v2]
In-Reply-To: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
Message-ID: <kv12sBzVbB6eNlPO8QWMybrHBF9SdQbpgdk2qGea3t8=.cf771109-23d1-425a-b3ed-82f4897305f1@github.com>

> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
> 
> - must not fire editStart event
> - must not update control's editing location
> 
> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
> 
> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  test cleanup, following review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/636/files
  - new: https://git.openjdk.java.net/jfx/pull/636/files/43015266..e51cb865

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=636&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=636&range=00-01

  Stats: 9 lines in 4 files changed: 0 ins; 2 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/636.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/636/head:pull/636

PR: https://git.openjdk.java.net/jfx/pull/636

From mhanl at openjdk.java.net  Fri Oct  1 17:26:38 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 1 Oct 2021 17:26:38 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit [v2]
In-Reply-To: <kv12sBzVbB6eNlPO8QWMybrHBF9SdQbpgdk2qGea3t8=.cf771109-23d1-425a-b3ed-82f4897305f1@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
 <kv12sBzVbB6eNlPO8QWMybrHBF9SdQbpgdk2qGea3t8=.cf771109-23d1-425a-b3ed-82f4897305f1@github.com>
Message-ID: <SA0K_vY4a-7SOHzepkR1fqPeHyYq7CUTiqIP58jjRa8=.aba69235-6351-4d9a-a50a-3a5aa0db1010@github.com>

On Fri, 1 Oct 2021 14:59:02 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
>> 
>> - must not fire editStart event
>> - must not update control's editing location
>> 
>> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
>> 
>> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cleanup, following review comments

Looks good!

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

Marked as reviewed by mhanl (Author).

PR: https://git.openjdk.java.net/jfx/pull/636

From github.com+1619657+nadernader99 at openjdk.java.net  Fri Oct  1 19:56:31 2021
From: github.com+1619657+nadernader99 at openjdk.java.net (John Nader)
Date: Fri, 1 Oct 2021 19:56:31 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v2]
In-Reply-To: <_mKtK6hkxEdctEMw2vAIys2-CYjTKyJ6GNJRhw2frzU=.3763bf2e-5253-4b5c-a188-b92edff1fc12@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.9efeb26e-13c8-4578-ae61-bf8181117bd2@github.com>
 <rrhzIAvEwqb5iIDbH7Wa4B_ZP6KBE8WKEaEZw3nMf9g=.d08b4ef4-c79b-4197-a1af-e1e82f0d0db4@github.com>
 <07T7kgEWMrueJarOLSddKscHGj8BApPL34M0GjaHM0o=.375d226c-f32d-4079-a003-29c706ab92ac@github.com>
 <5j7IrAa2UYQ86f0O9DO0VD4TAwqTvcDO9r2ON3ZNghM=.acbb01b1-cb25-46f3-aeb3-5354b86f0af6@github.com>
 <qYkYOv-R4ju6e8WO4Dx7ldg6d7UyT-KJ-i1H3a7fKxk=.e09576a2-df2f-4238-b09b-74cdefa8a22a@github.com>
 <wNlCt_SYur6B3pOvM0PlBn_PV_-cmsM_PsOCe6dGXw0=.0c13f3ef-80ff-40ef-aac5-40d6197ca735@github.com>
 <LmKcy9vHGWLns7HKB1WzkQ1Dt68lr0Lgr9xy2FAiCaM=.800345fa-f0c5-407b-952a-9740cac44e07@github.com>
 <oDC_gc4kKKxCTZPELktrDOezWnPy3ZFAuNUdBrK3yJg=.2437221c-523c-41da-a2af-17cbb3098251@github.com>
 <sh8e7vons3dC7nGKIjuYg3gRH0LeyMooTM1VVLanSCc=.e7b12ba2-6463-4cf9-8114-60a999671060@github.com>
 <HurgcNLMqbCv6XifiplB_aCwWRabLcmMRSCaRbsLEC4=.2603621a-9924-4e23-8e3a-975bda21b09f@github.com>
 <u4HkxgxlWE8eMFG7P296TPUC0CkeYurLo_p
 zAT_uQqM=.650a7b30-1b41-46a9-921e-38896763cfdb@github.com>
 <ZqUvt87D8Ks-HYTg2pUek_I5B4OiVea62zj2I5CW4AE=.403008c1-a636-4827-9c7b-92c0056176cd@github.com>
 <4KpG27kt2Hi-CugQNJoYwXyewRcEkfyHHVUsydZSSSw=.f4667620-b73c-4472-bfbc-5ddd9607d540@github.com>
 <WdBfmlm4xPnD-tbww3M09cc5zqzPOQsFfJlyA6o7ZcU=.b7aefaaa-0f52-41e2-9ffc-4ad0af4d3508@github.com>
 <YW_XrRAGzmzrtMkHrl5vrDs6ycr68bJmf-YXNoA5WOU=.71491cd1-759f-4e92-801c-e38cd8ab88b4@github.com>
 <ncGCQ5nk1rGRxNeIZjnVBE0I1gzs9hZVAkKSn1zbY8g=.c47ee142-4386-4909-b595-e26838674dae@github.com>
 <u6mRDZpF3GF0dNi_fCfnkq2w6Gy_7pctu0ydmnc1_5k=.90ab9945-a06d-403a-bd14-f13f0ba412e2@github.com>
 <2KEEPkz7O8R4cI804SdaphQYMurCScsyqus1ECh8nBw=.068af234-4b2a-4344-8bbf-5754fe377b61@github.com>
 <1u6nnq9D2gMrVpbNHHhST4-OiYGx1qHHZpO7tAbrDeQ=.a0a1bba8-0237-4a37-aae3-7b0ad5f722ad@github.com>
 <DoAjTO76u6vY5r_bEjtey-PQzVNwLcfsQkPGBcoHbCA=.999b67f0-9778-4363-af0e-cbba426a8d90@github.com>
 <AkO2JneZKSB6T74gn2dHJlN4w9Ng0RD6sHfcxDsqnL0=.a28c062d-9db6-4c92-95f0-9273f7f12f6c@
 github.com>
 <6LkHRaMUplUBWEW21xDr78kumXogW9oMKpFt-Jhhufw=.c0486d35-9a0a-4006-8891-998787764e50@github.com>
 <7g-EZUFLn2Tb_B7p0Z6sR5LUTnk5GAv2FkATwa1hja8=.29ac8306-a1d3-4b64-929b-177cf8acd12d@github.com>
 <L9DKmT3N1tHb8EqlBKXngFluy5syrpdBTvPzxWFKKTo=.2a4d1bb3-5c64-4b92-8ca4-3f47b81e2fee@github.com>
 <OvYLWNx4YQDy8IjwUzuQHr_VHf7P_BgYc_Vr0Zk-4IM=.aa3f6661-3662-4677-87a6-530eb900b92a@github.com>
 <N04LaFARufbBMOt8aZVwCb-35xeMNmrJxRIPX3zybZY=.749d586e-873c-46c4-8aad-09a1ed733631@github.com>
 <xYSuqAWSrz2pbFKKC0RpDehvxLe3vbIMu36DYpK19IY=.c275b2c1-e1fb-42b0-84ba-3d602dbd68d1@github.com>
 <RxJKlTGUU2MYqqVKiAumHxTRYjsg3rqNURJs2RWHcOg=.0505dc27-7fc4-4326-8753-eb432e50c079@github.com>
 <Hk7UyZfE0-v5KoF6shMLJT7zIsSLpNRB1G6wNH2l27g=.dc3dc32a-b115-4dbf-9c46-154e6a194248@github.com>
 <UYhjGRWfaWLn-PiS_rHf0cFK0I9aEoeG0eh9JU_GWYk=.f95481bc-a041-4965-9853-65b4f2e2559e@github.com>
 <mbjxk_UNYINinppeuxBXIs83uyRUqBUZSvRv_xzBC_A=.e563d604-0efd-4775-b01b-d6195bd27b01@github.com>
 <1-l0Bnh2MkUjs1shMElwal0g9TNPwmH2Oi
 qSod2idVc=.cf5f34fb-5f59-444c-8b22-a8b6ff1258c1@github.com>
 <Joi2slhsGtP8aX8Av6HFE0G5FWmNiyNrtgnUQSRCVYc=.b6d688a0-28bd-4e8f-9420-cc7b8b02a394@github.com>
 <xTMvvDWkDTJkviqF8t9gExOxwMn9P2LGWdjf8I0-0lo=.879274ef-9e21-4aa3-ae92-375be3e19339@github.com>
 <Pg0vqyvjultJwIq5DUTjJ284k8iTcKZ4rm1mLvT6vko=.95b9a211-583d-4ee9-935f-8dd306f9eff8@github.com>
 <fZ-3-PY64y4FCwX6Km7oDYftu893oQJmY2Wfn5WRAjw=.e00fe993-9bd1-4a10-89b8-e958c84801da@github.com>
 <_mKtK6hkxEdctEMw2vAIys2-CYjTKyJ6GNJRhw2frzU=.3763bf2e-5253-4b5c-a188-b92edff1fc12@github.com>
Message-ID: <2IK3twH508RdFXWnnv4vNJeWFvCaLZFhcTH-LInwdyA=.4d441730-9bc2-4a59-aaf5-3c0f516632a8@github.com>

On Fri, 2 Apr 2021 10:45:47 GMT, yosbits <github.com+7517141+yososs at openjdk.org> wrote:

>> dannygonzalez has updated the pull request incrementally.
>
> It seems that performance improvement PR often needs to make up for the lack of existing unit tests. However, this addition of unit tests should not be included in the same PR as it needs to be tested to meet the specifications before and after the change.
> 
> **I think we need a step to fix the lack of unit tests before the performance improvement patch.**
> 
> And care must be taken not to rely on internal implementations for this unit test so as not to hinder performance improvement. Some existing unit test code depends on the internal implementation, so some test changes may be needed.

This change is very near completion. According to @yososs, what remains is to split the work into two separate PRs. The first PR must contain the updated test covering additional cases to ensure backwards compatibility. The second should contain the performance enhancement changes. This will allow the tests to be merged into master first, to ensure the behavior is maintained before and after the performance enhancement.

I see that @dannygonzalez has not been able to continue this work. If possible and appropriate, I would like to finish this work. I have already setup a build environment and have verified that the updated tests alone pass when integrated with the master branch and have 100% coverage of the modified class.

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

PR: https://git.openjdk.java.net/jfx/pull/108

From github.com+1619657+nadernader99 at openjdk.java.net  Fri Oct  1 21:13:39 2021
From: github.com+1619657+nadernader99 at openjdk.java.net (John Nader)
Date: Fri, 1 Oct 2021 21:13:39 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
Message-ID: <urBj-D4Ma_G5IqvYcdOKfaNFFLyALpa57a1UGWfijVI=.20845ee8-1ed1-4c31-9d0a-1f5168a67003@github.com>

On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez <github.com+6702882+dannygonzalez at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8185886
>> 
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed.
>> 
>> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews.
>> 
>> This may alleviate some of the issues seen here:
>> 
>> TableView has a horrific performance with many columns #409
>> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033
>> 
>> JDK-8088394 : Huge memory consumption in TableView with too many columns
>> JDK-8166956: JavaFX TreeTableView slow scroll performance
>> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction
>> 
>> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html
>
> dannygonzalez has updated the pull request incrementally.

The behavior is the same between openjdk 16.0.2 and 17.0.0.1. The test to recreate the problem adds many nodes (Rectangle) to a parent Group. The process causes each node to add two invalidation listeners (disabledProperty and treeVisibleProperty) to the parent node [here](https://github.com/openjdk/jfx/blob/64aa92631fa5aad9293553e8dd174eab647de2f3/modules/javafx.graphics/src/main/java/javafx/scene/Node.java#L965) using ExpressionHelper.Generic.addListener(). When the children are cleared from the group the inefficient linear search through the listener array and remove occurs, two linear searches per child.

Here is the minimal application I am using to recreate the issue.


public class ClearGroupPerformance extends Application {

    private static final int GAP = 10;
    private static final int SIZE = 40;
    private Group groupBase;

    public static void main(String[] args) {

        launch(args);
    }

    @Override
    public void start(Stage stage) {

        int width = 10000;
        int height = 10000;

        ScrollPane scrollPane = new ScrollPane();
        StackPane root = createGroupRoot(width, height);
        scrollPane.setContent(root);

        Button clearGroupButton = new Button("Clear Group");
        clearGroupButton.onActionProperty().set(e -> {

            long startTime = System.nanoTime();
            ObservableList<Node> children = groupBase.getChildren();
            int totalChildren = children.size();
            children.clear();
            System.out.printf("Clearing %d nodes took %.2fms%n", totalChildren, (System.nanoTime()-startTime)/1_000_000.0);

        });

        BorderPane borderPane = new BorderPane();
        borderPane.setTop(clearGroupButton);
        borderPane.setCenter(scrollPane);

        Scene scene = new Scene(borderPane, 100, 100);
        stage.setScene(scene);
        stage.show();

    }

    private StackPane createGroupRoot(int width, int height) {

        groupBase = new Group();
        groupBase.getChildren().add(new Rectangle(width, height, new Color(0.5, 0.5, 0.5, 1.0)));

        for (int posX = GAP; posX + SIZE + GAP < width; posX += SIZE + GAP) {
            for (int posY = GAP; posY + SIZE + GAP < height; posY += SIZE + GAP) {
                Rectangle rectangle = new Rectangle(posX, posY, SIZE, SIZE);
                rectangle.setFill(Color.GREEN);

                groupBase.getChildren().add(rectangle);
            }
        }

        return new StackPane(groupBase);
    }

}

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

PR: https://git.openjdk.java.net/jfx/pull/108

From jhendrikx at openjdk.java.net  Sat Oct  2 02:48:43 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Sat, 2 Oct 2021 02:48:43 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
Message-ID: <1Te0tkgh24WpZSRUv4cMO7SAc_OwTuJtt0wlIrBYRKo=.6aad0a76-fef1-4f05-858f-b5d6193a71e6@github.com>

On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez <github.com+6702882+dannygonzalez at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8185886
>> 
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed.
>> 
>> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews.
>> 
>> This may alleviate some of the issues seen here:
>> 
>> TableView has a horrific performance with many columns #409
>> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033
>> 
>> JDK-8088394 : Huge memory consumption in TableView with too many columns
>> JDK-8166956: JavaFX TreeTableView slow scroll performance
>> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction
>> 
>> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html
>
> dannygonzalez has updated the pull request incrementally.

Thank you for the test case.  I see that this is indeed another issue, although again one that seems to be triggered by an excessive amount of listeners being added by `Node` to something higher up in the hierarchy.  Although I'm sure this is just a test to show the problem, work arounds would include organizing the rectangles in groups to avoid too many children under a single parent, or using Canvas.

Since the listeners added seem to be internal to `Node` to recursively keep track of disabled/visible state (and are not "optional", in other words, every child always registers them) it might be prudent to avoid this overhead and listener management completely.  This could be achieved by having the parent `Node` pro-actively inform its children about changes without needing listeners, for example by just calling a private method.  This should result in similar performance and would reduce memory overhead per node as there is no need for listener instances.

There is a 3rd property as well involved in the case there are transformations applied which could be given the same treatment (localToSceneTransformProperty).

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

PR: https://git.openjdk.java.net/jfx/pull/108

From kevin.rushforth at oracle.com  Sat Oct  2 13:56:47 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 2 Oct 2021 06:56:47 -0700
Subject: [External] : Aw: Re: JavaFX snapping and scale
In-Reply-To: <trinity-2cc660d2-2623-4be5-899c-655e3da751e1-1633098403049@3c-app-webde-bap09>
References: <trinity-1d1ef66a-d9a6-4ae5-9902-54db08908161-1632735699982@3c-app-webde-bap32>
 <f5438258-4e87-21a2-f933-59dfffd970c8@oracle.com>
 <trinity-2cc660d2-2623-4be5-899c-655e3da751e1-1633098403049@3c-app-webde-bap09>
Message-ID: <ea13aea1-6fe8-445b-3a5e-8f62a1358ccb@oracle.com>

By the time it is rendered, it will be transformed into the scaled 
space. So the actual coordinate in screen space will be 13.

-- Kevin

On 10/1/2021 7:26 AM, Marius Hanl wrote:
> Thanks for your answer.
> Then one more question: How is a non-integer value rendered then?
> Say we have snapped x value of 10.4 (scale 1.25). As we can just 
> render on a whole pixel, what will happen?
> - Marius
> *Gesendet:*?Dienstag, 28. September 2021 um 01:57 Uhr
> *Von:*?"Kevin Rushforth" <kevin.rushforth at oracle.com>
> *An:*?openjfx-dev at openjdk.java.net
> *Betreff:*?Re: JavaFX snapping and scale
> The basic idea behind snapping to pixel boundaries (which is optional,
> but on by default) is that 2D primitives will look more crisp if they
> are rendered on whole pixel boundaries. When there is no HiDPI involved,
> the operation of snapping to a pixel boundary can be done with a simple
> floor, round, or ceil operation (depending on what you are snapping).
> When there is a HIDPI scale involved, the value in user space needs to
> be chosen such that the transformed value ends up on a pixel boundary.
> That's why you will see snapped values that aren't on integer boundaries
> when the HiDPI scale is, say 1.25.
>
> In the case you ran into, the problem might be that the snapping isn't
> happening in the right place in the computation. Also, it seems quite
> possible that the clipping isn't being calculated correctly with respect
> to pixel snapping.
>
> You can take a look at JDK-8211294 [1] which was fixed by PR #308 [2]
> for a recent example of a HiDPI bug affecting ScrollPane that was fixed.
> There are a couple of follow-on issues that came out of that issue,
> although I suspect they aren't relevant to the bug you are looking at.
>
> -- Kevin
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8211294 
> <https://bugs.openjdk.java.net/browse/JDK-8211294>
> [2] https://github.com/openjdk/jfx/pull/308 
> <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/308__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H6gdZzIT$>
>
> On 9/27/2021 2:41 AM, Marius Hanl wrote:
> > I recently tried to fix "TableView: visual glitch at borders on
> > horizontal scrolling".
> > Ticket: [1]https://bugs.openjdk.java.net/browse/JDK-8218745 
> <https://bugs.openjdk.java.net/browse/JDK-8218745>
> > PR: [2]https://github.com/openjdk/jfx/pull/630 
> <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/630__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H8fP3AKI$>
> >
> > As also written in the PR I have problems understanding the
> > snapping/scaling of JavaFX.
> > Here in short what I found out:
> > - Snapping fixed the issue for a scale of 1 or 2, but not for a scale
> > like 1.25 or 1.5
> > --- Also VirtualFlow is the only occurence where we set the layoutX of
> > a clip (might be the problem?)
> > - This visual glitch only happens sometimes when the x value is a
> > decimal number, e.g. 12.66 (never when it's a round number like 13)
> > - Math.round(..) or a cast to int fixed this (for all scales), but is
> > probably not the correct solution or maybe only fixing a symptom here
> >
> > Which leads to my question where may some of you can help me:
> > - How does JavaFX renders a node when e.g. x is a decimal number? How
> > many pixel are used then?
> > - And does a decimal number make sense (Why we e.g. don't round the
> > value), which looks like it works fine and doesn't result in visual
> > glitches
> >
> > Also information/insights about fixes made in the past which relates
> > with this are welcome.
> > I saw that there were quite some issues with a scale other then 1 in
> > the past.
> >
> > Note: If the result is that everything works as expected chances are
> > there might a generic problem with snapping/layout/rendering somewhere
> > then.
> > Any information are welcome and feel free to also have a look at the
> > PR.
> >
> > -- Marius
> >
> > References
> >
> > 1. https://bugs.openjdk.java.net/browse/JDK-8218745 
> <https://bugs.openjdk.java.net/browse/JDK-8218745>
> > 2. https://github.com/openjdk/jfx/pull/630 
> <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/630__;!!ACWV5N9M2RV99hQ!YDG10_6aLWHF6oDpo3JIKfgBDwkjcbFb75u8jaIuZp0zCY0tmAExinA93yn4H8fP3AKI$>


From michaelstrau2 at gmail.com  Sat Oct  2 23:54:40 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Sun, 3 Oct 2021 01:54:40 +0200
Subject: JavaFX snapping and scale
In-Reply-To: <trinity-7563f62d-3a81-4cb8-9f82-00d153b2171d-1632844435493@3c-app-webde-bap36>
References: <trinity-1d1ef66a-d9a6-4ae5-9902-54db08908161-1632735699982@3c-app-webde-bap32>
 <CAJEpuXQu_TTNSfTwrUfWeueW6cC1XaJ0H4HUwfHRAyDZJxtNmw@mail.gmail.com>
 <trinity-7563f62d-3a81-4cb8-9f82-00d153b2171d-1632844435493@3c-app-webde-bap36>
Message-ID: <CAJEpuXQYJ+xMNb7hTvJyZWet39w4gwfXXheSuABNes0gLqo+aQ@mail.gmail.com>

No, we don't always render at integer coordinates. If you place a
control at 10,10 and disable pixel snapping, it'll end up at 12.5,12.5
(with 125% scaling) in render coordinates.

The process of coloring pixels on the output texture based on triangle
polygons is called rasterization. For each pixel, the rasterizer
determines whether it's inside of the polygon to be drawn. If the
pixel is inside, it will be colored according to the output of a
shader program; if it's not inside, it will be unaffected. More
precisely, a pixel is inside of a polygon if its center point is
inside of the polygon.

So we do render at non-integer coordinates, but it's the
Direct3D/OpenGL/etc. rasterization rules that decide whether or not a
pixel will appear on the output texture.

Regarding the PR: that's a solution for a different problem.


On Tue, Sep 28, 2021 at 5:53 PM Marius Hanl <mariushanl at web.de> wrote:
>
> Thanks for your reply.
>
> Does that mean that we will always render at a round number, e.g. 13, never on a decimal number?
> Because then I'm wondering how we can render at a decimal number given we can't split a pixel.
>
> If this actually fixes the problem it might be worth a revisit.
> Can I try this out as is?
> If so and it actually fixes my problem/makes it a lot easier this PR will probably get more attention and can benefit from it.
>

From github.com+1619657+nadernader99 at openjdk.java.net  Mon Oct  4 06:46:35 2021
From: github.com+1619657+nadernader99 at openjdk.java.net (John Nader)
Date: Mon, 4 Oct 2021 06:46:35 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
Message-ID: <WpKiYOb0nJVsQdwBrwhpyDMI8zHXkoPJSNkxK7x6MJc=.7111a60b-f3ee-4112-89f5-20e5ae5e4519@github.com>

On Wed, 14 Apr 2021 12:33:23 GMT, dannygonzalez <github.com+6702882+dannygonzalez at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8185886
>> 
>> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays to improve listener removal speed.
>> 
>> This was due to the removal of listeners in TableView taking up to 50% of CPU time on the JavaFX Application thread when scrolling/adding rows to TableViews.
>> 
>> This may alleviate some of the issues seen here:
>> 
>> TableView has a horrific performance with many columns #409
>> https://github.com/javafxports/openjdk-jfx/issues/409#event-2206515033
>> 
>> JDK-8088394 : Huge memory consumption in TableView with too many columns
>> JDK-8166956: JavaFX TreeTableView slow scroll performance
>> JDK-8185887: TableRowSkinBase fails to correctly virtualise cells in horizontal direction
>> 
>> OpenJFX mailing list thread: TableView slow vertical scrolling with 300+ columns
>> https://mail.openjdk.java.net/pipermail/openjfx-dev/2020-January/024780.html
>
> dannygonzalez has updated the pull request incrementally.

Your points regarding unnecessary default listeners are valid.

The question now is should the work done on this PR be abandoned. It addresses a current performance limitation taking complexity from O(n log n) to O(1). It appears to be well isolated with low risk to backwards compatibility. The reason work was stopped was a concern that the tests should go first in a separate PR.

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

PR: https://git.openjdk.java.net/jfx/pull/108

From kcr at openjdk.java.net  Mon Oct  4 06:46:40 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 4 Oct 2021 06:46:40 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <urBj-D4Ma_G5IqvYcdOKfaNFFLyALpa57a1UGWfijVI=.20845ee8-1ed1-4c31-9d0a-1f5168a67003@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
 <urBj-D4Ma_G5IqvYcdOKfaNFFLyALpa57a1UGWfijVI=.20845ee8-1ed1-4c31-9d0a-1f5168a67003@github.com>
Message-ID: <EeHK0UckSCJT5weooTYDcBznedwJ1grWM5nXBmf79IQ=.8d678c57-f129-4f4f-a024-d10432725476@github.com>

On Fri, 1 Oct 2021 21:11:01 GMT, John Nader <github.com+1619657+nadernader99 at openjdk.org> wrote:

> Here is the minimal application I am using to recreate the issue.

I'll attach the test case you provided to the bug report.

> The question now is should the work done on this PR be abandoned. It addresses a current performance limitation taking complexity from O(n log n) to O(1).

That is a fair question, but it begs two additional questions. Are there enough real world examples where performance is being hurt by using an ArrayList to justify the effort and risk (more on that below)? If so, are there other solutions that would reduce the number of listeners needed? The original problems that motivated this fix were largely addressed by [JDK-8252935](https://bugs.openjdk.java.net/browse/JDK-8252935) / PR #185 and [JDK-8252811](https://bugs.openjdk.java.net/browse/JDK-8252811) / PR #298.

> It appears to be well isolated with low risk to backwards compatibility. The reason work was stopped was a concern that the tests should go first in a separate PR.

I disagree that this is a low risk change. This proposed fix touches a fundamental area used by all bindings, and does so in a way that will increase memory usage -- and might negatively impact performance -- in the common case of a small number of listeners. By unconditionally switching from an `ArrayList` to a `HashSet`, the memory required is significantly increased, which will be most noticeable for the common case of only a few listeners. An adaptive solution, which starts out using an `ArrayList` and dynamically switches to a `LinkedHashSet` (which preserves notification order...I know it isn't specified, but changing that is likely to break some applications) when crossing some threshold of the number of listeners, could mitigate this concern at the cost of added complexity.

If you still want to pursue this, you will need to do a fair amount of work to provide the additional tests that will be needed, to motivate the need for this enhancement (given that the original reasons are mostly addressed), and to resolve the issues that were raised in this PR. The mechanics of doing this are pretty easy. First, read the [CONTRIBUTING guideline](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md), specifically the part about signing the OCA, and create a new PR starting from this one. You would then add the author of this PR as a contributor.

In the mean time, I'm going to move this PR to Draft (which I should have done long ago), since it stalled and not being actively worked on or reviewed.

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

PR: https://git.openjdk.java.net/jfx/pull/108

From mhanl at openjdk.java.net  Mon Oct  4 07:13:31 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Mon, 4 Oct 2021 07:13:31 GMT
Subject: RFR: 8274669: Dialog sometimes ignores max height
Message-ID: <lZJ9tGD-E_JoxrLbrhCE47UNp70ABIMNZHP75T0N_u0=.23b97afc-344b-4177-a97c-87fcccbc4b9a@github.com>

This PR fixes a visual glitch which may happen when showing a dialog.
When a max height is set and the pref height of the dialog content is bigger the dialog starts to flicker between the max height and the pref height.

This happens because in one case the height is not bound between the min and the max height (-> max height is ignored).
- First layout pass: The dialog will incorrectly resize to a the pref height, which is bigger than the max height
- Second layout pass: The dialog will correctly resize to the max height
- repeat

The fix is to bound the height there as well (Fix in **layoutChildren()**).
Example where a red stackpane has a bigger pref height then the max height of the dialog (see also example in ticket):

https://user-images.githubusercontent.com/66004280/135734463-03b422f4-710d-4436-9715-c91bdb768d76.mp4

* only the max height test fails before and succeeds after.

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

Commit messages:
 - 8274669: Dialog sometimes ignores max height

Changes: https://git.openjdk.java.net/jfx/pull/637/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=637&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274669
  Stats: 108 lines in 2 files changed: 107 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/637.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/637/head:pull/637

PR: https://git.openjdk.java.net/jfx/pull/637

From hjohn at xs4all.nl  Mon Oct  4 08:02:03 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Mon, 4 Oct 2021 10:02:03 +0200
Subject: Enhancements for JavaFX 18
In-Reply-To: <747d56a4-20c2-873d-2167-b62a794ce34b@bestsolution.at>
References: <c65a8300-a99a-0903-7226-d411bc16d18a@oracle.com>
 <009017d1-572b-e03c-f5c7-d045b3f57592@xs4all.nl>
 <747d56a4-20c2-873d-2167-b62a794ce34b@bestsolution.at>
Message-ID: <b7f66b79-d197-6b93-b6ab-150a8f6f386b@xs4all.nl>

I missed this question.

There are several external libaries available to help with these kinds 
of bindings.  There is EasyBind, ReactFX and an attempt of my own 
(https://github.com/hjohn/hs.jfx.eventstream).

They all have a different way of addressing this, but they do all have 
one thing in common: they all require that you wrap ObservableValues in 
their own extended variant of ObservableValue.  EasyBind has 
"MonadicObervableValue", ReactFX has "Val" and "Var" and my own attempt 
has "ValueStream".

Effectively this means you will get two types of properties in your 
JavaFX application, and you'll need to update standard properties like 
ObjectProperty to the type the framework provides to get the extra 
features. Interop between "old" and "new" code requires wrapping and 
sometimes unwrapping.

Integrating this into JavaFX's ObservableValue directly avoids all these 
wrappers and all the extra work that entails for the user of fluent 
bindings.

With this base in place, external libraries can provide streams and 
complicated mapping functions (ReactFX especially has an overabundance 
of features, most of which too niche to include into JavaFX directly).

That's not the only advantage however. When these are integrated, JavaFX 
internals can take advantage of them as well. Managing of cascading 
properties (usually done manually in JavaFX code, Bindings#select is not 
usually used) will be much cleaner and simpler.

Also the lazy bindings part of this MR can be used to avoid creating 
listeners for properties that aren't used themselves -- this allows for 
example Node to provide convience properties (like tree visibility) 
without having to  pre-emptively add listeners. This is not possible 
currently without consuming additional memory for every Node instance.

Finally, it also would serve as a type safe replacement for 
Bindings#select which is something that I think the team behind FX has 
been wanting to address for quite a while now.

--John

On 12/09/2021 01:38, Tom Schindl wrote:
> I have not looked at the code yet but why does this have to be part of
> OpenJFX and can not be implemented as an external library?
>
> Tom
>
> Am 05.08.21 um 00:25 schrieb John Hendrikx:
>> Perhaps:
>>
>> Fluent bindings for ObservableValue
>> https://github.com/openjdk/jfx/pull/434
>>
>> It was received well I think, and there was some interest from Nir
>> Lisker to work on a proposal.
>>
>> --John
>>
>> On 30/07/2021 14:56, Kevin Rushforth wrote:
>>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
>>> and enhancement requests for JavaFX 18. It's the summer, so there may be
>>> delays as some people are out at various times (including me), but I
>>> would like to get some of the outstanding enhancement requests moving
>>> over the next few weeks.
>>>
>>> Specifically, I'd like to see the following proceed:
>>>
>>> * Transparent backgrounds in WebView
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>>> PR: https://github.com/openjdk/jfx/pull/563
>>>
>>> * Add DirectionalLight
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>>> PR: https://github.com/openjdk/jfx/pull/548
>>>
>>> * CSS pseudoclasses :focus-visible and :focus-within
>>> https://bugs.openjdk.java.net/browse/JDK-8268225
>>> PR: https://github.com/openjdk/jfx/pull/475
>>>
>>> * Improve property system to facilitate correct usage (minus the binary
>>> incompatible API change)
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>>>
>>> And maybe the following:
>>>
>>> * Add CSS themes as a first-class concept (need a consensus on how to
>>> proceed)
>>>
>>> * Undecorated interactive stage style (still in early discussion, but
>>> the concept looks interesting and useful)
>>>
>>> There are probably others I'm forgetting.
>>>
>>> Each of the above should be discussed in their own thread on openjfx-dev
>>> rather than a reply to this thread.
>>>
>>> -- Kevin
>>>
>>>
>

From florian.kirmaier at gmail.com  Mon Oct  4 08:30:40 2021
From: florian.kirmaier at gmail.com (Florian Kirmaier)
Date: Mon, 4 Oct 2021 10:30:40 +0200
Subject: How to publish sources and javadoc?
Message-ID: <CA+4mSqZi2HSzV_1qefN3aybQv-6Da69nuV8BpAtoOmXQ7xYGhA@mail.gmail.com>

Hi everyone,

When I use the task sdk / publish / publishToMavenLocal, I can not see a
jar with the sources.
But they are always part of the official JavaFX release:
https://repo1.maven.org/maven2/org/openjfx/javafx-controls/17.0.0.1/
And the javadoc also deems to be missing.
How can the javadoc and sources be generated and added to the Maven release?

Florian Kirmaier

From aghaisas at openjdk.java.net  Mon Oct  4 09:19:10 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 4 Oct 2021 09:19:10 GMT
Subject: RFR: 8274433: All Cells: misbehavior of startEdit [v2]
In-Reply-To: <kv12sBzVbB6eNlPO8QWMybrHBF9SdQbpgdk2qGea3t8=.cf771109-23d1-425a-b3ed-82f4897305f1@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
 <kv12sBzVbB6eNlPO8QWMybrHBF9SdQbpgdk2qGea3t8=.cf771109-23d1-425a-b3ed-82f4897305f1@github.com>
Message-ID: <_tmHsaJaAlvCQZZErVhcjbFu-vQeuWQ9_R9vCp_rggA=.83921a54-89dc-4f80-957b-248135287f26@github.com>

On Fri, 1 Oct 2021 14:59:02 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
>> 
>> - must not fire editStart event
>> - must not update control's editing location
>> 
>> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
>> 
>> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test cleanup, following review comments

Marked as reviewed by aghaisas (Reviewer).

The fix is fine!

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

PR: https://git.openjdk.java.net/jfx/pull/636

From fastegal at openjdk.java.net  Mon Oct  4 10:55:09 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 4 Oct 2021 10:55:09 GMT
Subject: Integrated: 8274433: All Cells: misbehavior of startEdit
In-Reply-To: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
References: <CADfx0zqc2y5SNP1307JETO8WQkbj2GzOjsPt-GD9rQ=.40c645b5-7f78-49ed-ae16-388c6cd1a457@github.com>
Message-ID: <tmYaPqr-AqhahoSHLuajYHRexmWZ01WCbeR19hJJ5ZM=.6af437cf-4a2a-4a00-8f51-e90f24512b5f@github.com>

On Thu, 30 Sep 2021 12:00:16 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> The misbehavior happens if (super) startEdit didn't succeed (== !cell.isEditing):
> 
> - must not fire editStart event
> - must not update control's editing location
> 
> fix is to back out of startEdit if super.startEdit doesn't switch the cell into editing mode
> 
> Added tests that failed/passed before/after the fix. Note that for Tree-, Table-, TreeTableCell one of the added tests would be a false green due to those cells not updating the editing location on its control [JDK-8187474](https://bugs.openjdk.java.net/browse/JDK-8187474), so it's ignore until that's fixed.

This pull request has now been integrated.

Changeset: 2c86e0fc
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/2c86e0fc81074f6ad49b798c891a358a5fe15f94
Stats:     105 lines in 8 files changed: 105 ins; 0 del; 0 mod

8274433: All Cells: misbehavior of startEdit

Reviewed-by: mhanl, aghaisas

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

PR: https://git.openjdk.java.net/jfx/pull/636

From github.com+1619657+nadernader99 at openjdk.java.net  Mon Oct  4 11:48:13 2021
From: github.com+1619657+nadernader99 at openjdk.java.net (John Nader)
Date: Mon, 4 Oct 2021 11:48:13 GMT
Subject: RFR: 8252936: Optimize removal of listeners from
 ExpressionHelper.Generic [v3]
In-Reply-To: <EeHK0UckSCJT5weooTYDcBznedwJ1grWM5nXBmf79IQ=.8d678c57-f129-4f4f-a024-d10432725476@github.com>
References: <CRkpJHYmaXdYuuq9vQtk2FEiwGdyLM0n_Pzzk_ldDVw=.c11af293-1e8a-4987-a470-f3136fa34254@github.com>
 <8PfWi6iX0wbLsLjqKBp9m3iJKAJEZwMnbz3Mff9BbzU=.fb03e01a-121c-488c-aa5b-2f21a4836837@github.com>
 <urBj-D4Ma_G5IqvYcdOKfaNFFLyALpa57a1UGWfijVI=.20845ee8-1ed1-4c31-9d0a-1f5168a67003@github.com>
 <EeHK0UckSCJT5weooTYDcBznedwJ1grWM5nXBmf79IQ=.8d678c57-f129-4f4f-a024-d10432725476@github.com>
Message-ID: <FIzoFnrp8bJzDoW3y6dAvKocD_nZIL_2YeZ0fBHJwtU=.8f39937a-bc5b-413e-bbd4-d6f992aff8e4@github.com>

On Sat, 2 Oct 2021 13:35:51 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The behavior is the same between openjdk 16.0.2 and 17.0.0.1. The test to recreate the problem adds many nodes (Rectangle) to a parent Group. The process causes each node to add two invalidation listeners (disabledProperty and treeVisibleProperty) to the parent node [here](https://github.com/openjdk/jfx/blob/64aa92631fa5aad9293553e8dd174eab647de2f3/modules/javafx.graphics/src/main/java/javafx/scene/Node.java#L965) using ExpressionHelper.Generic.addListener(). When the children are cleared from the group the inefficient linear search through the listener array and remove occurs, two linear searches per child.
>> 
>> Here is the minimal application I am using to recreate the issue.
>> 
>> 
>> public class ClearGroupPerformance extends Application {
>> 
>>     private static final int GAP = 10;
>>     private static final int SIZE = 40;
>>     private Group groupBase;
>> 
>>     public static void main(String[] args) {
>> 
>>         launch(args);
>>     }
>> 
>>     @Override
>>     public void start(Stage stage) {
>> 
>>         int width = 10000;
>>         int height = 10000;
>> 
>>         ScrollPane scrollPane = new ScrollPane();
>>         StackPane root = createGroupRoot(width, height);
>>         scrollPane.setContent(root);
>> 
>>         Button clearGroupButton = new Button("Clear Group");
>>         clearGroupButton.onActionProperty().set(e -> {
>> 
>>             long startTime = System.nanoTime();
>>             ObservableList<Node> children = groupBase.getChildren();
>>             int totalChildren = children.size();
>>             children.clear();
>>             System.out.printf("Clearing %d nodes took %.2fms%n", totalChildren, (System.nanoTime()-startTime)/1_000_000.0);
>> 
>>         });
>> 
>>         BorderPane borderPane = new BorderPane();
>>         borderPane.setTop(clearGroupButton);
>>         borderPane.setCenter(scrollPane);
>> 
>>         Scene scene = new Scene(borderPane, 100, 100);
>>         stage.setScene(scene);
>>         stage.show();
>> 
>>     }
>> 
>>     private StackPane createGroupRoot(int width, int height) {
>> 
>>         groupBase = new Group();
>>         groupBase.getChildren().add(new Rectangle(width, height, new Color(0.5, 0.5, 0.5, 1.0)));
>> 
>>         for (int posX = GAP; posX + SIZE + GAP < width; posX += SIZE + GAP) {
>>             for (int posY = GAP; posY + SIZE + GAP < height; posY += SIZE + GAP) {
>>                 Rectangle rectangle = new Rectangle(posX, posY, SIZE, SIZE);
>>                 rectangle.setFill(Color.GREEN);
>> 
>>                 groupBase.getChildren().add(rectangle);
>>             }
>>         }
>> 
>>         return new StackPane(groupBase);
>>     }
>> 
>> }
>
>> Here is the minimal application I am using to recreate the issue.
> 
> I'll attach the test case you provided to the bug report.
> 
>> The question now is should the work done on this PR be abandoned. It addresses a current performance limitation taking complexity from O(n log n) to O(1).
> 
> That is a fair question, but it begs two additional questions. Are there enough real world examples where performance is being hurt by using an ArrayList to justify the effort and risk (more on that below)? If so, are there other solutions that would reduce the number of listeners needed? The original problems that motivated this fix were largely addressed by [JDK-8252935](https://bugs.openjdk.java.net/browse/JDK-8252935) / PR #185 and [JDK-8252811](https://bugs.openjdk.java.net/browse/JDK-8252811) / PR #298.
> 
>> It appears to be well isolated with low risk to backwards compatibility. The reason work was stopped was a concern that the tests should go first in a separate PR.
> 
> I disagree that this is a low risk change. This proposed fix touches a fundamental area used by all bindings, and does so in a way that will increase memory usage -- and might negatively impact performance -- in the common case of a small number of listeners. By unconditionally switching from an `ArrayList` to a `HashSet`, the memory required is significantly increased, which will be most noticeable for the common case of only a few listeners. An adaptive solution, which starts out using an `ArrayList` and dynamically switches to a `LinkedHashSet` (which preserves notification order...I know it isn't specified, but changing that is likely to break some applications) when crossing some threshold of the number of listeners, could mitigate this concern at the cost of added complexity.
> 
> If you still want to pursue this, you will need to do a fair amount of work to provide the additional tests that will be needed, to motivate the need for this enhancement (given that the original reasons are mostly addressed), and to resolve the issues that were raised in this PR. The mechanics of doing this are pretty easy. First, read the [CONTRIBUTING guideline](https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md), specifically the part about signing the OCA, and create a new PR starting from this one. You would then add the author of this PR as a contributor.
> 
> In the mean time, I'm going to move this PR to Draft (which I should have done long ago), since it stalled and not being actively worked on or reviewed.

@kevinrushforth makes an important point I was missing. Functionally this change is isolated but the memory overhead of a new data structure used by every node would risk performance degradation across many existing applications. I now see that the recommendation @hjohn to avoid adding unnecessary listeners by default should be prioritized over a faster listener lookup data structure. This will clarifies why work on this PR is currently back in draft status.

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

PR: https://git.openjdk.java.net/jfx/pull/108

From aghaisas at openjdk.java.net  Mon Oct  4 12:12:11 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 4 Oct 2021 12:12:11 GMT
Subject: RFR: 8274137: TableView scrollbar/header misaligned when
 reloading data [v3]
In-Reply-To: <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
References: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
 <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
Message-ID: <Z51rKgdCRvfOQUHyg68jImjESEll-U99mYDjipthFpw=.f699c345-b56a-49f9-8c40-edc6a527dd88@github.com>

On Mon, 27 Sep 2021 05:27:25 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene.
>> Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time.
>> 
>> A test agains VirtualFlow has been added that will fail before the change and pass afterwards.
>
> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274137: TableView scrollbar/header misaligned when reloading data
>   
>   Remove @Override annotations unrelated to fix.

Marked as reviewed by aghaisas (Reviewer).

Fix is fine!

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

PR: https://git.openjdk.java.net/jfx/pull/629

From nlisker at gmail.com  Mon Oct  4 15:51:31 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Mon, 4 Oct 2021 18:51:31 +0300
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <CA+0ynh8Zsw5B6tBQKxG7VzzrQEMj1-YLs1BaLxXyCRFOhY=LPw@mail.gmail.com>
 <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl>
 <CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com>
 <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl>
 <CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com>
 <a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl>
 <CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com>
 <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl>
 <CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com>
 <ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl>
 <CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com>
 <a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl>
 <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
Message-ID: <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>

I think that a PR can be created. The only point we need to decide is about
the subscription models we talked about above. ReactFX uses something
different for each, you use the same. That can determine if we need
different classes for each binding type.

I can create the JBS issue for this one and a draft CSR if you want.

On Tue, Sep 21, 2021 at 1:36 PM Nir Lisker <nlisker at gmail.com> wrote:

> The OrElseBinding is incorrect
>>
>
> Yes, that was a typo with the order of the arguments in the ternary
> statement.
>
> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>> think the tests would become pretty unreadable and less useful /
>> thourough otherwise).
>>
>> What are the options?
>>
>
> This is a bigger question. Kevin will have to answer that.
>
> As for the subscription model: flat map has a more complicated one, but
>> orElse, orElseGet and map all have the same one.
>>
>
> From what I saw, ReactFX uses a different subscription model for these. I
> could have misread it.
>
> The messages will need to be written from the perspective of the Binding
>> class then IMHO.
>>
>
> That's fine.
>
> As for the Optional methods, I'll have a look in my code base and see if
> the places I would like to use them at will become irrelevant anyway with
> the fluent bindings. I'm fine with proceeding with the current names of the
> proposed methods.
>
> On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>
>> I need to get you the tests I wrote, unfortunately, they're JUnit 5,
>> please see the tests here:
>>
>>
>> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
>>
>> The OrElseBinding is incorrect, the compute value should read:
>>
>>      protected T computeValue() {
>>        T value = source.getValue();
>>        return value == null ? constant : value;
>>      }
>>
>> Similar for OrElseGetBinding.
>>
>> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>> think the tests would become pretty unreadable and less useful /
>> thourough otherwise).
>>
>> What are the options?
>>
>> - Integrate a nested runner (there is an Apache 2.0 licensed one
>> available)
>> - Create our own nested runner (about 200 lines of code)
>> - Can we introduce JUnit 5?
>> - Rewrite to plain JUnit 4?
>>
>> Let me know, and I can integrate them.
>>
>> --John
>>
>> On 19/09/2021 02:12, Nir Lisker wrote:
>> > I've played around with the implementation and pushed a modified
>> > prototype to the sandbox [1]. I ended up with something similar to
>> ReactFX:
>> > the orElse and orElseGet methods have their own binding classes that
>> > extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The
>> > reason being that both their compute value and their subscription models
>> > are slightly different. While they can be matched to MapBinding like you
>> > did, it entails a bit of a roundabout way in my opinion. Creating a
>> > supplier for the constant value of orElse somewhat defeats the purpose I
>> > think.
>>
>> I have no strong opinion here, just wanted to keep the MR small. The
>> supplier should be an inline candidate, but creating a separate class is
>> fine too.
>>
>> As for the subscription model: flat map has a more complicated one, but
>> orElse, orElseGet and map all have the same one.
>>
>> > In addition, I think that it's fine to move the arguments' null checks
>> to
>> > the binding classes themselves, even if it's a couple of levels deeper
>> on
>> > the stack, while adding a message in the 2nd argument of
>> > Objects.requireNonNull for clarity. These classes are "self-contained"
>> so
>> > it makes sense for them to check their arguments. They might be used in
>> > other places, perhaps in the public Bindings class.
>>
>> The messages will need to be written from the perspective of the Binding
>> class then IMHO.
>>
>> > I also moved the subscription-related methods from ObservableValue to
>> > static methods in Subscription, at least for now, to defer the API
>> related
>> > to Subscription.
>>
>> Sounds good.
>>
>> > The branch doesn't compile because I didn't finish working on the
>> > visibility issue, but it's close enough to what I envision it like for
>> the
>> > first PR.
>>
>> I've ported the changes over to my branch and ran the tests on it, they
>> all pass apart from the above mentioned problem in the OrElse bindings.
>>
>> > As for the java,util.Optional methods, I indeed did something like
>> > `x.orElse(5).getValue()` in the past in other cases, but this approach
>> > creates a new binding just to get the wrapped value out, which is very
>> > inefficient. (In one case I did booleanValue.isNull().get(), which
>> creates
>> > a boolean binding, because isPresent() does not exist). I would like to
>> see
>> > what others think about the Optional methods, The binding method
>> variants
>> > are much more important, but I want to avoid a name clash if the
>> Optional
>> > ones will have support.
>>
>> Okay, some more things to consider:
>>
>> ObservableValue is not an Optional, their get methods respond
>> differently with Optional#get throwing an exception when null -- the
>> #orElse is a necessity; this is not the case for ObservableValue#getValue.
>>
>> When creating mapping chains, you are going to do this because you want
>> to bind this to another property or to listen on it (with subscribe).
>> You don't want to do this as a one time thing. If you are creating a
>> chain just to calculate a value you can just do this directly. Instead of:
>>
>>      widthProperty().map(x -> x * 2).getValue()
>>
>> You'd do:
>>
>>      getWidth() * 2;
>>
>> With flat mapping however this is not as easy:
>>
>>      [1]
>>      node.sceneProperty()
>>        .flatMap(Scene::windowProperty)
>>        .flatMap(Window::showingProperty)
>>        .orElse(false);
>>
>> You could try:
>>
>>      node.getScene().getWindow().isShowing();
>>
>> But that will not work when Scene or Window is null.  You'd have to
>> write it as:
>>
>>      [2]
>>      Optional.ofNullable(node.getScene())
>>         .map(Scene::getWindow)
>>         .map(Window::isShowing)
>>         .orElse(false);
>>
>> If you only offer a "specialized" orElse, you'd still need to create
>> several bindings:
>>
>>      [3]
>>      node.sceneProperty()
>>        .flatMap(Scene::windowProperty)
>>        .flatMap(Window::showingProperty)
>>        .orElse2(false);  // orElse which returns a value not a binding
>>
>> If you compare [2] (which is possible now) with [3] the difference is
>> minimal. A bit more ceremony at the start for [2] but a shorter, cleaner
>> and faster mapping (no bindings and no need to use the property methods).
>>
>> Now, if you already HAVE the binding for some other purpose, then it is
>> highly likely it also already has an #orElse that is needed as part of
>> the binding. In that case calling #getValue is fine without much need
>> for another #orElse variant.
>>
>> --John
>>
>> >
>> > [1]
>> >
>> https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
>> >
>> > On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>> >
>> >>
>> >>
>> >> On 15/09/2021 02:28, Nir Lisker wrote:
>> >>>     Sorry, I'm not quite sure what you mean by this. Could you
>> elaborate?
>> >>>     The methods orElse and orElseGet are present in the PoC, and I
>> think
>> >>>     they're highly useful to have to deal with nulls.
>> >>>
>> >>>
>> >>> The methods that you call orElse and orElseGet return an
>> >>> ObservableValue<T>. The Optional methods with the same names return
>> the
>> >>> wrapped value (of type T). For comparison, ReactFX has:
>> >>> T getOrElse(T defaultValue)
>> >>> T getOrSupply(Supplier<? extends T> defaultSupplier)
>> >>> Val<T> orElseConst(T other)
>> >>> Val<T> orElse(ObservableValue<T> other)
>> >>
>> >> I see what you mean now. The methods from java.util.Optional will
>> return
>> >> an unwrapped value, while the ones from ObservableValue in the PoC
>> >> return an ObservableValue<T>, but they have the same name.
>> >>
>> >> So java.util.Optional offers:
>> >>
>> >>      T orElse(T other)
>> >>      T orElseGet(Supplier<? extends T> supplier)
>> >>
>> >> And the PoC:
>> >>
>> >>      ObservableValue<T> orElse(T alternativeValue)
>> >>      ObservableValue<T> orElseGet(Supplier<? extends T> supplier)
>> >>
>> >> The main difference is in the returned types. Personally, I think it is
>> >> rarely useful for a binding to be queried directly and I've never used
>> >> the #getOrElse or #getOrSupply variants that ReactFX offers. On top of
>> >> that:
>> >>
>> >>      x.orElse(5).getValue()    ===    x.getOrElse(5)
>> >>
>> >> So it introduces another method in the interface to avoid having to
>> >> write ".getValue()". The opposite, introducing only the "unwrapped"
>> >> variants would still require the "wrapped" variants to be present as
>> well.
>> >>
>> >> So, what I would suggest is to not add variants for #getOrElse and
>> >> #getOrSupply at all as they are of questionable value and would just
>> >> bloat the API for a bit less typing. In that case I think we can still
>> >> use the signatures as they are.
>> >>
>> >> ReactFX also offers:
>> >>
>> >>      Val<T> orElse(ObservableValue<T> other)
>> >>
>> >> This is another rarely used feature IMHO, and I think Optional#or would
>> >> a better match for this functionality:
>> >>
>> >>      Optional<T> or(Supplier<? extends Optional<? extends T>> supplier)
>> >>
>> >> In the POC the signature would be:
>> >>
>> >>      ObservableValue<T> or(
>> >>        Supplier<? extends ObservableValue<? extends T>> supplier
>> >>      )
>> >>
>> >> I didn't implement this one in the PoC to keep it small, but I did
>> >> implement this in my JavaFX EventStream library before.
>> >>
>> >>> So it deals with both getting the wrapped value in null cases and with
>> >>> getting a "dynamic value" in null cases. I find the Optional-like
>> method
>> >>> 'T getOrElse(T defaultValue)' useful (along with others such as
>> >>> ifPresent because Optional is just useful for dealing with wrapped
>> >>> values). What I'm saying is that we should be careful with the names
>> if
>> >>> we include both "constant" and "dynamic" versions of 'orElse'-like
>> >> methods.
>> >>
>> >> I think #ifPresent can be added, not so sure about the usefulness of
>> >> #getOrElse (see above).
>> >>
>> >>>     The null check in ReactFX's #computeValue is
>> >>>     actually checking the result of the mapping function, not whether
>> the
>> >>>     function instance itself was null.
>> >>>
>> >>> I didn't mean the null-ness of the map argument. What I meant was that
>> >>> there is this implementation, which is similar to what ReactFX does:
>> >>
>> >> Sorry, I see it now. You have a good point, the current implementation
>> >> indeed wraps another Lambda to add the null check which could have been
>> >> done in #computeValue. I think it would be a good move to avoid the
>> >> extra lambda simply because the end result would be more readable --
>> any
>> >> performance improvement would be a bonus, I don't know if there will be
>> >> any.
>> >>
>> >>> As for my points 3 and 4, I'll have to try and play with the
>> >>> implementation myself, which will be easier to do when there is some
>> PR
>> >>> in the works.
>> >>
>> >> Perhaps this is useful:
>> >> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx
>> >>
>> >> When you add this as a maven dependency to your project, you will get
>> >> the new PoC functionality. It basically uses the Maven shade plugin to
>> >> replace a few classes in javafx-base -- I use this sometimes to fix
>> bugs
>> >> I need fixed immediately by patching jfx, but found it also works very
>> >> nicely to experiment with this PoC.
>> >>
>> >> Also, the PoC PR compiles fine, it may need rebasing.
>> >>
>> >>>     To close "Bindings.select*(): add new type-safe template based API
>> >>>     instead of legacy-style set of methods" we'd need the
>> flatMap/select
>> >>>     method to be included.
>> >>>
>> >>> Yes. I think that we can include flatMap in this iteration, perhaps as
>> >>> a separate PR?
>> >>
>> >> That should be no problem, I can split it up.
>> >>
>> >>>     I don't think we really need specialized methods for primitives
>> (or
>> >> at
>> >>>     least, not right away).  At this point the primitive versions only
>> >>>     really differ in what value they'd return if the binding would be
>> >> null
>> >>>     and perhaps they do a little less boxing/unboxing. Since you can
>> >> select
>> >>>     the default value with #orElse which is more flexible. I don't see
>> >> much
>> >>>     use to add those variants.
>> >>>
>> >>> I agree, I would avoid bloating the primitive specialization classes
>> for
>> >>> now, especially when Valhalla is planned to take care of those.
>> >>
>> >> Yes, I think we can easily do without for now.
>> >>
>> >>>     The ticket is a bit unclear as I can't see what type "x" is.
>> >>>
>> >>> Yes, but I got the impression that either way it can be solved with
>> map
>> >>> (or flatMap).
>> >>
>> >> Agreed.
>> >>
>> >> --John
>> >>
>> >
>>
>

From michaelstrau2 at gmail.com  Mon Oct  4 18:37:46 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Mon, 4 Oct 2021 20:37:46 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
Message-ID: <CAJEpuXSM-n0wB+qeo1vCDM6iuJa+NMoEz79yYH9Fb2gMy2fgdg@mail.gmail.com>

A little bit of bikeshedding here: I think this feature should be
thought of as a type-safe version of `Bindings.select`, which should
also be reflected in the terminology used (i.e. not map/flatMap). The
terminology, combined with the frequent comparisons to reactive
libraries might make it seem like an attempt to bring reactive
programming to JavaFX. That will certainly not happen, as JavaFX is
not (and never will be) a reactive framework. Naming it `select` will
convey the purpose and its place within JavaFX in a better and clearer
way.

On Wed, Mar 24, 2021 at 10:49 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>
> I just wanted to draw some attention to a recent proof of concept I made
> in this pull request: https://github.com/openjdk/jfx/pull/434
>
> It is based on the work I did in
> https://github.com/hjohn/hs.jfx.eventstream which is in part based on
> work done in ReactFX by Tomas Mikula. The PR itself however shares no
> code with ReactFX and is
> completely written by me.
>
> If there is interest, I'm willing to invest more time in smoothing out
> the API and documentation, investigating further how this would interact
> with the primitive types and adding unit test coverage (I have extensive
> tests, but thesea are written in JUnit 5, so they would require
> conversion or JavaFX could move to support JUnit 5).
>
> What follows below is the text of the PR for easy reading. Feedback is
> appreciated.
>
> ================
>
> This is a proof of concept of how fluent bindings could be introduced to
> JavaFX. The main benefit of fluent bindings are ease of use, type safety
> and less surprises. Features:
>
> Flexible Mappings
> Map the contents of a property any way you like with map, or map nested
> properties with flatMap.
>
> Lazy
> The bindings created are lazy, which means they are always invalid when
> not themselves observed. This allows for easier garbage collection (once
> the last observer is removed, a chain of bindings will stop observing
> their parents) and less listener management when dealing with nested
> properties. Furthermore, this allows inclusion of such bindings in
> classes such as Node without listeners being created when the binding
> itself is not used (this would allow for the inclusion of a
> treeShowingProperty in Node without creating excessive listeners, see
> this fix I did in an earlier PR: #185)
>
> Null Safe
> The map and flatMap methods are skipped, similar to java.util.Optional
> when the value they would be mapping is null. This makes mapping nested
> properties with flatMap trivial as the null case does not need to be
> taken into account in a chain like this:
> node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty).
> Instead a default can be provided with orElse or orElseGet.
>
> Conditional Bindings
> Bindings can be made conditional using the conditionOn method. A
> conditional binding retains its last value when its condition is false.
> Conditional bindings donot observe their source when the condition is
> false, allowing developers to automatically stop listening to properties
> when a certain condition is met. A major use of this feature is to have
> UI components that need to keep models updated which may outlive the UI
> conditionally update the long lived model only when the UI is showing.
>
> Some examples:
>
> void mapProperty() {
>    // Standard JavaFX:
>    label.textProperty().bind(Bindings.createStringBinding(() ->
> text.getValueSafe().toUpperCase(), text));
>
>    // Fluent: much more compact, no need to handle null
>    label.textProperty().bind(text.map(String::toUpperCase));
> }
>
> void calculateCharactersLeft() {
>    // Standard JavaFX:
>
> label.textProperty().bind(text.length().negate().add(100).asString().concat("
> characters left"));
>
>    // Fluent: slightly more compact and more clear (no negate needed)
>    label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() +
> " characters left"));
> }
>
> void mapNestedValue() {
>    // Standard JavaFX:
>    label.textProperty().bind(Bindings.createStringBinding(
>      () -> employee.get() == null ? ""
>          : employee.get().getCompany() == null ? ""
>          : employee.get().getCompany().getName(),
>      employee
>    ));
>
>    // Fluent: no need to handle nulls everywhere
>    label.textProperty().bind(
>      employee.map(Employee::getCompany)
>              .map(Company::getName)
>              .orElse("")
>    );
> }
>
> void mapNestedProperty() {
>    // Standard JavaFX:
>    label.textProperty().bind(
>      Bindings.when(Bindings.selectBoolean(label.sceneProperty(),
> "window", "showing"))
>        .then("Visible")
>        .otherwise("Not Visible")
>    );
>
>    // Fluent: type safe
>    label.textProperty().bind(label.sceneProperty()
>      .flatMap(Scene::windowProperty)
>      .flatMap(Window::showingProperty)
>      .orElse(false)
>      .map(showing -> showing ? "Visible" : "Not Visible")
>    );
> }
>
> void updateLongLivedModelWhileAvoidingMemoryLeaks() {
>    // Standard JavaFX: naive, memory leak; UI won't get garbage collected
>    listView.getSelectionModel().selectedItemProperty().addListener(
>      (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current)
>    );
>
>    // Standard JavaFX: no leak, but stops updating after a while
>    listView.getSelectionModel().selectedItemProperty().addListener(
>      new WeakChangeListener<>(
>        (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current)
>      )
>    );
>
>    // Standard JavaFX: fixed version
>    listenerReference = (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current);
>
>    listView.getSelectionModel().selectedItemProperty().addListener(
>      new WeakChangeListener<>(listenerReference)
>    );
>
>    // Fluent: naive, memory leak... fluent won't solve this...
>    listView.getSelectionModel().selectedItemProperty()
>        .subscribe(longLivedModel.lastSelectedProperty()::set);
>
>    // Fluent: conditional update when control visible
>
>    // Create a property which is only true when the UI is visible:
>    ObservableValue<Boolean> showing = listView.sceneProperty()
>        .flatMap(Scene::windowProperty)
>        .flatMap(Window::showingProperty)
>        .orElse(false);
>
>    // Use showing property to automatically disconnect long lived model
>    // allowing garbage collection of the UI:
>    listView.getSelectionModel().selectedItemProperty()
>      .conditionOn(showing)
>      .subscribe(longLivedModel.lastSelectedProperty()::set);
>
>    // Note that the 'showing' property can be provided in multiple ways:
>    // - create manually (can be re-used for multiple bindings though)
>    // - create with a helper: Nodes.showing(Node node) ->
> ObservableValue<Boolean>
>    // - make it part of the Node class; as the fluent bindings only bind
> themselves
>    //   to their source when needed (lazy binding), this won't create
> overhead
>    //   for each node in the scene
> }
> Note that this is based on ideas in ReactFX and my own experiments in
> https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion
> that this is much better directly integrated into JavaFX, and I'm hoping
> this proof of concept will be able to move such an effort forward.
>
> --John

From hjohn at xs4all.nl  Mon Oct  4 21:50:56 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Mon, 4 Oct 2021 23:50:56 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <CA+0ynh8Zsw5B6tBQKxG7VzzrQEMj1-YLs1BaLxXyCRFOhY=LPw@mail.gmail.com>
 <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl>
 <CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com>
 <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl>
 <CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com>
 <a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl>
 <CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com>
 <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl>
 <CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com>
 <ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl>
 <CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com>
 <a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl>
 <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
 <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
Message-ID: <a7219d99-6775-b1e1-d267-2b33b648a293@xs4all.nl>



On 04/10/2021 17:51, Nir Lisker wrote:
> I think that a PR can be created. The only point we need to decide is
> about the subscription models we talked about above. ReactFX uses
> something different for each, you use the same. That can determine if we
> need different classes for each binding type.

We can introduce classes for these in any case if that keeps things more 
clean; they're not public (after your change) so we can change our minds 
later.

I'm not sure I see the difference though, ReactFX does the same kind of 
observations to keep the bindings up to date. Here's a comparison:

OrElseConst (ReactFX) vs OrElseBinding
--------------------------------------

     protected Subscription connect() {
         return Val.observeInvalidations(src, obs -> invalidate());
     }

------

     protected Subscription observeInputs() {
         return Subscription.subscribeInvalidations(source, 
this::invalidate); // start observing source
     }

OrElseGetBinding (no equivalent in ReactFX)
-------------------------------------------

     @Override
     protected Subscription observeInputs() {
         return Subscription.subscribeInvalidations(source, 
this::invalidate); // start observing source
     }

FlatMapped (ReactFX) vs FlatMapBinding
--------------------------------------

     protected final Subscription connect() {
         return Val.observeInvalidations(src, obs -> srcInvalidated())
                 .and(this::stopObservingSelected);
     }

     private void stopObservingSelected() {
         if(selectedSubscription != null) {
             selectedSubscription.unsubscribe();
             selectedSubscription = null;
         }
     }

------

     protected Subscription observeInputs() {
         Subscription subscription = 
source.subscribeInvalidations(this::invalidate);

         return () -> {
             subscription.unsubscribe();
             mappedSubscription.unsubscribe();
             mappedSubscription = Subscription.EMPTY;
         };
     }

In both ReactFX and the PoC we see that FlatMapping requires a more 
complicated subscription. As a FlatMap observes the original observable 
and the result of the flat mapping, when unsubscribing two listeners 
need to be unsubscribed.

As for the OrElse and OrElseGet, I just noticed ReactFX does not have an 
#orElseGet equivalent. Closest thing is #getOrSupply but that doesn't 
create a binding and is just a convenience method to get the current 
value.

This does make me wonder how useful #orElseGet really would be -- I 
think we should leave it out for now, it is easy to introduce later if 
there is a real use case for it (I checked what I code I have, and I 
never used it so far, it was only used to delegate #orElse to #orElseGet 
which is pretty useless).

I think one more thing to decide is the naming of flatMap, there seems 
to be some support for using "select" as a name instead. I personally 
don't mind the name as for me flatMap just implies a map with the 
additional step of flattening the result (stripping the extra wrapper, 
be it Optional, Stream or in our case, ObservableValue).

I don't think that confusion with reactive programming is good argument 
to not use this name, as neither Optional nor Stream have resulted in 
such confusion.

> I can create the JBS issue for this one and a draft CSR if you want.

It would be great to move this forward.  If we can't borrow one of the 
existing JBS issues then it would be good to create a new one, I can do 
that, I can rewrite the text of the PoC MR a bit for this purpose. As 
for a CSR, I'm not quite sure what that entails so it might be best if 
you draft one.

The draft PR is mostly missing the JUnit test coverage now, which I can 
take care off. I can also take care of the other changes we discussed 
that may not be there yet. And I'll take another critical look at the 
documentation and see if it still matches with what was discussed.

I've tried pushing the JUnit 5 upgrade as well, but I don't think it 
will arrive in time (or perhaps it will).  What I can do is convert my 
JUnit 5 tests to JUnit 4, and once JUnit 5 is available I can revert that.

--John

From hjohn at xs4all.nl  Mon Oct  4 22:34:31 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Tue, 5 Oct 2021 00:34:31 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <CAJEpuXSM-n0wB+qeo1vCDM6iuJa+NMoEz79yYH9Fb2gMy2fgdg@mail.gmail.com>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <CAJEpuXSM-n0wB+qeo1vCDM6iuJa+NMoEz79yYH9Fb2gMy2fgdg@mail.gmail.com>
Message-ID: <337eb0db-5b3a-53d3-c4a1-b0812eb0bf74@xs4all.nl>



On 04/10/2021 20:37, Michael Strau? wrote:
> A little bit of bikeshedding here: I think this feature should be
> thought of as a type-safe version of `Bindings.select`, which should
> also be reflected in the terminology used (i.e. not map/flatMap). The
> terminology, combined with the frequent comparisons to reactive
> libraries might make it seem like an attempt to bring reactive
> programming to JavaFX. That will certainly not happen, as JavaFX is
> not (and never will be) a reactive framework. Naming it `select` will
> convey the purpose and its place within JavaFX in a better and clearer
> way.

The PoC is much more than that though. It allows arbitrary conversion of 
property values and creating bindings for these that are automatically 
kept updated. It not only removes the need for Bindings#select but also 
sort of obsoletes many of the functions offered by 
Object/String/IntegerExpression as for most of these #map can be used.

The terms #map and #flatMap (flatten + map) come from functional 
programming which predates reactive programming, and do not necessarily 
imply a stream as used by reactive. Java 8's Optional is a good example.

Both Optional and Stream are part of Java 8 and I contend are far better 
known within the Java community than reactive programming. Therefore the 
terms map and flatMap should be quite well understood by now.

--John

> On Wed, Mar 24, 2021 at 10:49 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>>
>> I just wanted to draw some attention to a recent proof of concept I made
>> in this pull request: https://github.com/openjdk/jfx/pull/434
>>
>> It is based on the work I did in
>> https://github.com/hjohn/hs.jfx.eventstream which is in part based on
>> work done in ReactFX by Tomas Mikula. The PR itself however shares no
>> code with ReactFX and is
>> completely written by me.
>>
>> If there is interest, I'm willing to invest more time in smoothing out
>> the API and documentation, investigating further how this would interact
>> with the primitive types and adding unit test coverage (I have extensive
>> tests, but thesea are written in JUnit 5, so they would require
>> conversion or JavaFX could move to support JUnit 5).
>>
>> What follows below is the text of the PR for easy reading. Feedback is
>> appreciated.
>>
>> ================
>>
>> This is a proof of concept of how fluent bindings could be introduced to
>> JavaFX. The main benefit of fluent bindings are ease of use, type safety
>> and less surprises. Features:
>>
>> Flexible Mappings
>> Map the contents of a property any way you like with map, or map nested
>> properties with flatMap.
>>
>> Lazy
>> The bindings created are lazy, which means they are always invalid when
>> not themselves observed. This allows for easier garbage collection (once
>> the last observer is removed, a chain of bindings will stop observing
>> their parents) and less listener management when dealing with nested
>> properties. Furthermore, this allows inclusion of such bindings in
>> classes such as Node without listeners being created when the binding
>> itself is not used (this would allow for the inclusion of a
>> treeShowingProperty in Node without creating excessive listeners, see
>> this fix I did in an earlier PR: #185)
>>
>> Null Safe
>> The map and flatMap methods are skipped, similar to java.util.Optional
>> when the value they would be mapping is null. This makes mapping nested
>> properties with flatMap trivial as the null case does not need to be
>> taken into account in a chain like this:
>> node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty).
>> Instead a default can be provided with orElse or orElseGet.
>>
>> Conditional Bindings
>> Bindings can be made conditional using the conditionOn method. A
>> conditional binding retains its last value when its condition is false.
>> Conditional bindings donot observe their source when the condition is
>> false, allowing developers to automatically stop listening to properties
>> when a certain condition is met. A major use of this feature is to have
>> UI components that need to keep models updated which may outlive the UI
>> conditionally update the long lived model only when the UI is showing.
>>
>> Some examples:
>>
>> void mapProperty() {
>>    // Standard JavaFX:
>>    label.textProperty().bind(Bindings.createStringBinding(() ->
>> text.getValueSafe().toUpperCase(), text));
>>
>>    // Fluent: much more compact, no need to handle null
>>    label.textProperty().bind(text.map(String::toUpperCase));
>> }
>>
>> void calculateCharactersLeft() {
>>    // Standard JavaFX:
>>
>> label.textProperty().bind(text.length().negate().add(100).asString().concat("
>> characters left"));
>>
>>    // Fluent: slightly more compact and more clear (no negate needed)
>>    label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() +
>> " characters left"));
>> }
>>
>> void mapNestedValue() {
>>    // Standard JavaFX:
>>    label.textProperty().bind(Bindings.createStringBinding(
>>      () -> employee.get() == null ? ""
>>          : employee.get().getCompany() == null ? ""
>>          : employee.get().getCompany().getName(),
>>      employee
>>    ));
>>
>>    // Fluent: no need to handle nulls everywhere
>>    label.textProperty().bind(
>>      employee.map(Employee::getCompany)
>>              .map(Company::getName)
>>              .orElse("")
>>    );
>> }
>>
>> void mapNestedProperty() {
>>    // Standard JavaFX:
>>    label.textProperty().bind(
>>      Bindings.when(Bindings.selectBoolean(label.sceneProperty(),
>> "window", "showing"))
>>        .then("Visible")
>>        .otherwise("Not Visible")
>>    );
>>
>>    // Fluent: type safe
>>    label.textProperty().bind(label.sceneProperty()
>>      .flatMap(Scene::windowProperty)
>>      .flatMap(Window::showingProperty)
>>      .orElse(false)
>>      .map(showing -> showing ? "Visible" : "Not Visible")
>>    );
>> }
>>
>> void updateLongLivedModelWhileAvoidingMemoryLeaks() {
>>    // Standard JavaFX: naive, memory leak; UI won't get garbage collected
>>    listView.getSelectionModel().selectedItemProperty().addListener(
>>      (obs, old, current) ->
>> longLivedModel.lastSelectedProperty().set(current)
>>    );
>>
>>    // Standard JavaFX: no leak, but stops updating after a while
>>    listView.getSelectionModel().selectedItemProperty().addListener(
>>      new WeakChangeListener<>(
>>        (obs, old, current) ->
>> longLivedModel.lastSelectedProperty().set(current)
>>      )
>>    );
>>
>>    // Standard JavaFX: fixed version
>>    listenerReference = (obs, old, current) ->
>> longLivedModel.lastSelectedProperty().set(current);
>>
>>    listView.getSelectionModel().selectedItemProperty().addListener(
>>      new WeakChangeListener<>(listenerReference)
>>    );
>>
>>    // Fluent: naive, memory leak... fluent won't solve this...
>>    listView.getSelectionModel().selectedItemProperty()
>>        .subscribe(longLivedModel.lastSelectedProperty()::set);
>>
>>    // Fluent: conditional update when control visible
>>
>>    // Create a property which is only true when the UI is visible:
>>    ObservableValue<Boolean> showing = listView.sceneProperty()
>>        .flatMap(Scene::windowProperty)
>>        .flatMap(Window::showingProperty)
>>        .orElse(false);
>>
>>    // Use showing property to automatically disconnect long lived model
>>    // allowing garbage collection of the UI:
>>    listView.getSelectionModel().selectedItemProperty()
>>      .conditionOn(showing)
>>      .subscribe(longLivedModel.lastSelectedProperty()::set);
>>
>>    // Note that the 'showing' property can be provided in multiple ways:
>>    // - create manually (can be re-used for multiple bindings though)
>>    // - create with a helper: Nodes.showing(Node node) ->
>> ObservableValue<Boolean>
>>    // - make it part of the Node class; as the fluent bindings only bind
>> themselves
>>    //   to their source when needed (lazy binding), this won't create
>> overhead
>>    //   for each node in the scene
>> }
>> Note that this is based on ideas in ReactFX and my own experiments in
>> https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion
>> that this is much better directly integrated into JavaFX, and I'm hoping
>> this proof of concept will be able to move such an effort forward.
>>
>> --John
>

From hjohn at xs4all.nl  Tue Oct  5 10:33:51 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Tue, 5 Oct 2021 12:33:51 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <CA+0ynh8Zsw5B6tBQKxG7VzzrQEMj1-YLs1BaLxXyCRFOhY=LPw@mail.gmail.com>
 <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl>
 <CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com>
 <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl>
 <CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com>
 <a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl>
 <CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com>
 <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl>
 <CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com>
 <ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl>
 <CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com>
 <a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl>
 <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
 <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
Message-ID: <f265c50d-3496-c67f-e732-c4cdba1ad5bb@xs4all.nl>

I've created https://bugs.openjdk.java.net/browse/JDK-8274771

Please have a look.

--John

On 04/10/2021 17:51, Nir Lisker wrote:
> I think that a PR can be created. The only point we need to decide is about
> the subscription models we talked about above. ReactFX uses something
> different for each, you use the same. That can determine if we need
> different classes for each binding type.
>
> I can create the JBS issue for this one and a draft CSR if you want.
>
> On Tue, Sep 21, 2021 at 1:36 PM Nir Lisker <nlisker at gmail.com> wrote:
>
>> The OrElseBinding is incorrect
>>>
>>
>> Yes, that was a typo with the order of the arguments in the ternary
>> statement.
>>
>> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>>> think the tests would become pretty unreadable and less useful /
>>> thourough otherwise).
>>>
>>> What are the options?
>>>
>>
>> This is a bigger question. Kevin will have to answer that.
>>
>> As for the subscription model: flat map has a more complicated one, but
>>> orElse, orElseGet and map all have the same one.
>>>
>>
>> From what I saw, ReactFX uses a different subscription model for these. I
>> could have misread it.
>>
>> The messages will need to be written from the perspective of the Binding
>>> class then IMHO.
>>>
>>
>> That's fine.
>>
>> As for the Optional methods, I'll have a look in my code base and see if
>> the places I would like to use them at will become irrelevant anyway with
>> the fluent bindings. I'm fine with proceeding with the current names of the
>> proposed methods.
>>
>> On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>>
>>> I need to get you the tests I wrote, unfortunately, they're JUnit 5,
>>> please see the tests here:
>>>
>>>
>>> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
>>>
>>> The OrElseBinding is incorrect, the compute value should read:
>>>
>>>      protected T computeValue() {
>>>        T value = source.getValue();
>>>        return value == null ? constant : value;
>>>      }
>>>
>>> Similar for OrElseGetBinding.
>>>
>>> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>>> think the tests would become pretty unreadable and less useful /
>>> thourough otherwise).
>>>
>>> What are the options?
>>>
>>> - Integrate a nested runner (there is an Apache 2.0 licensed one
>>> available)
>>> - Create our own nested runner (about 200 lines of code)
>>> - Can we introduce JUnit 5?
>>> - Rewrite to plain JUnit 4?
>>>
>>> Let me know, and I can integrate them.
>>>
>>> --John
>>>
>>> On 19/09/2021 02:12, Nir Lisker wrote:
>>>> I've played around with the implementation and pushed a modified
>>>> prototype to the sandbox [1]. I ended up with something similar to
>>> ReactFX:
>>>> the orElse and orElseGet methods have their own binding classes that
>>>> extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The
>>>> reason being that both their compute value and their subscription models
>>>> are slightly different. While they can be matched to MapBinding like you
>>>> did, it entails a bit of a roundabout way in my opinion. Creating a
>>>> supplier for the constant value of orElse somewhat defeats the purpose I
>>>> think.
>>>
>>> I have no strong opinion here, just wanted to keep the MR small. The
>>> supplier should be an inline candidate, but creating a separate class is
>>> fine too.
>>>
>>> As for the subscription model: flat map has a more complicated one, but
>>> orElse, orElseGet and map all have the same one.
>>>
>>>> In addition, I think that it's fine to move the arguments' null checks
>>> to
>>>> the binding classes themselves, even if it's a couple of levels deeper
>>> on
>>>> the stack, while adding a message in the 2nd argument of
>>>> Objects.requireNonNull for clarity. These classes are "self-contained"
>>> so
>>>> it makes sense for them to check their arguments. They might be used in
>>>> other places, perhaps in the public Bindings class.
>>>
>>> The messages will need to be written from the perspective of the Binding
>>> class then IMHO.
>>>
>>>> I also moved the subscription-related methods from ObservableValue to
>>>> static methods in Subscription, at least for now, to defer the API
>>> related
>>>> to Subscription.
>>>
>>> Sounds good.
>>>
>>>> The branch doesn't compile because I didn't finish working on the
>>>> visibility issue, but it's close enough to what I envision it like for
>>> the
>>>> first PR.
>>>
>>> I've ported the changes over to my branch and ran the tests on it, they
>>> all pass apart from the above mentioned problem in the OrElse bindings.
>>>
>>>> As for the java,util.Optional methods, I indeed did something like
>>>> `x.orElse(5).getValue()` in the past in other cases, but this approach
>>>> creates a new binding just to get the wrapped value out, which is very
>>>> inefficient. (In one case I did booleanValue.isNull().get(), which
>>> creates
>>>> a boolean binding, because isPresent() does not exist). I would like to
>>> see
>>>> what others think about the Optional methods, The binding method
>>> variants
>>>> are much more important, but I want to avoid a name clash if the
>>> Optional
>>>> ones will have support.
>>>
>>> Okay, some more things to consider:
>>>
>>> ObservableValue is not an Optional, their get methods respond
>>> differently with Optional#get throwing an exception when null -- the
>>> #orElse is a necessity; this is not the case for ObservableValue#getValue.
>>>
>>> When creating mapping chains, you are going to do this because you want
>>> to bind this to another property or to listen on it (with subscribe).
>>> You don't want to do this as a one time thing. If you are creating a
>>> chain just to calculate a value you can just do this directly. Instead of:
>>>
>>>      widthProperty().map(x -> x * 2).getValue()
>>>
>>> You'd do:
>>>
>>>      getWidth() * 2;
>>>
>>> With flat mapping however this is not as easy:
>>>
>>>      [1]
>>>      node.sceneProperty()
>>>        .flatMap(Scene::windowProperty)
>>>        .flatMap(Window::showingProperty)
>>>        .orElse(false);
>>>
>>> You could try:
>>>
>>>      node.getScene().getWindow().isShowing();
>>>
>>> But that will not work when Scene or Window is null.  You'd have to
>>> write it as:
>>>
>>>      [2]
>>>      Optional.ofNullable(node.getScene())
>>>         .map(Scene::getWindow)
>>>         .map(Window::isShowing)
>>>         .orElse(false);
>>>
>>> If you only offer a "specialized" orElse, you'd still need to create
>>> several bindings:
>>>
>>>      [3]
>>>      node.sceneProperty()
>>>        .flatMap(Scene::windowProperty)
>>>        .flatMap(Window::showingProperty)
>>>        .orElse2(false);  // orElse which returns a value not a binding
>>>
>>> If you compare [2] (which is possible now) with [3] the difference is
>>> minimal. A bit more ceremony at the start for [2] but a shorter, cleaner
>>> and faster mapping (no bindings and no need to use the property methods).
>>>
>>> Now, if you already HAVE the binding for some other purpose, then it is
>>> highly likely it also already has an #orElse that is needed as part of
>>> the binding. In that case calling #getValue is fine without much need
>>> for another #orElse variant.
>>>
>>> --John
>>>
>>>>
>>>> [1]
>>>>
>>> https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
>>>>
>>>> On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx <hjohn at xs4all.nl> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 15/09/2021 02:28, Nir Lisker wrote:
>>>>>>     Sorry, I'm not quite sure what you mean by this. Could you
>>> elaborate?
>>>>>>     The methods orElse and orElseGet are present in the PoC, and I
>>> think
>>>>>>     they're highly useful to have to deal with nulls.
>>>>>>
>>>>>>
>>>>>> The methods that you call orElse and orElseGet return an
>>>>>> ObservableValue<T>. The Optional methods with the same names return
>>> the
>>>>>> wrapped value (of type T). For comparison, ReactFX has:
>>>>>> T getOrElse(T defaultValue)
>>>>>> T getOrSupply(Supplier<? extends T> defaultSupplier)
>>>>>> Val<T> orElseConst(T other)
>>>>>> Val<T> orElse(ObservableValue<T> other)
>>>>>
>>>>> I see what you mean now. The methods from java.util.Optional will
>>> return
>>>>> an unwrapped value, while the ones from ObservableValue in the PoC
>>>>> return an ObservableValue<T>, but they have the same name.
>>>>>
>>>>> So java.util.Optional offers:
>>>>>
>>>>>      T orElse(T other)
>>>>>      T orElseGet(Supplier<? extends T> supplier)
>>>>>
>>>>> And the PoC:
>>>>>
>>>>>      ObservableValue<T> orElse(T alternativeValue)
>>>>>      ObservableValue<T> orElseGet(Supplier<? extends T> supplier)
>>>>>
>>>>> The main difference is in the returned types. Personally, I think it is
>>>>> rarely useful for a binding to be queried directly and I've never used
>>>>> the #getOrElse or #getOrSupply variants that ReactFX offers. On top of
>>>>> that:
>>>>>
>>>>>      x.orElse(5).getValue()    ===    x.getOrElse(5)
>>>>>
>>>>> So it introduces another method in the interface to avoid having to
>>>>> write ".getValue()". The opposite, introducing only the "unwrapped"
>>>>> variants would still require the "wrapped" variants to be present as
>>> well.
>>>>>
>>>>> So, what I would suggest is to not add variants for #getOrElse and
>>>>> #getOrSupply at all as they are of questionable value and would just
>>>>> bloat the API for a bit less typing. In that case I think we can still
>>>>> use the signatures as they are.
>>>>>
>>>>> ReactFX also offers:
>>>>>
>>>>>      Val<T> orElse(ObservableValue<T> other)
>>>>>
>>>>> This is another rarely used feature IMHO, and I think Optional#or would
>>>>> a better match for this functionality:
>>>>>
>>>>>      Optional<T> or(Supplier<? extends Optional<? extends T>> supplier)
>>>>>
>>>>> In the POC the signature would be:
>>>>>
>>>>>      ObservableValue<T> or(
>>>>>        Supplier<? extends ObservableValue<? extends T>> supplier
>>>>>      )
>>>>>
>>>>> I didn't implement this one in the PoC to keep it small, but I did
>>>>> implement this in my JavaFX EventStream library before.
>>>>>
>>>>>> So it deals with both getting the wrapped value in null cases and with
>>>>>> getting a "dynamic value" in null cases. I find the Optional-like
>>> method
>>>>>> 'T getOrElse(T defaultValue)' useful (along with others such as
>>>>>> ifPresent because Optional is just useful for dealing with wrapped
>>>>>> values). What I'm saying is that we should be careful with the names
>>> if
>>>>>> we include both "constant" and "dynamic" versions of 'orElse'-like
>>>>> methods.
>>>>>
>>>>> I think #ifPresent can be added, not so sure about the usefulness of
>>>>> #getOrElse (see above).
>>>>>
>>>>>>     The null check in ReactFX's #computeValue is
>>>>>>     actually checking the result of the mapping function, not whether
>>> the
>>>>>>     function instance itself was null.
>>>>>>
>>>>>> I didn't mean the null-ness of the map argument. What I meant was that
>>>>>> there is this implementation, which is similar to what ReactFX does:
>>>>>
>>>>> Sorry, I see it now. You have a good point, the current implementation
>>>>> indeed wraps another Lambda to add the null check which could have been
>>>>> done in #computeValue. I think it would be a good move to avoid the
>>>>> extra lambda simply because the end result would be more readable --
>>> any
>>>>> performance improvement would be a bonus, I don't know if there will be
>>>>> any.
>>>>>
>>>>>> As for my points 3 and 4, I'll have to try and play with the
>>>>>> implementation myself, which will be easier to do when there is some
>>> PR
>>>>>> in the works.
>>>>>
>>>>> Perhaps this is useful:
>>>>> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx
>>>>>
>>>>> When you add this as a maven dependency to your project, you will get
>>>>> the new PoC functionality. It basically uses the Maven shade plugin to
>>>>> replace a few classes in javafx-base -- I use this sometimes to fix
>>> bugs
>>>>> I need fixed immediately by patching jfx, but found it also works very
>>>>> nicely to experiment with this PoC.
>>>>>
>>>>> Also, the PoC PR compiles fine, it may need rebasing.
>>>>>
>>>>>>     To close "Bindings.select*(): add new type-safe template based API
>>>>>>     instead of legacy-style set of methods" we'd need the
>>> flatMap/select
>>>>>>     method to be included.
>>>>>>
>>>>>> Yes. I think that we can include flatMap in this iteration, perhaps as
>>>>>> a separate PR?
>>>>>
>>>>> That should be no problem, I can split it up.
>>>>>
>>>>>>     I don't think we really need specialized methods for primitives
>>> (or
>>>>> at
>>>>>>     least, not right away).  At this point the primitive versions only
>>>>>>     really differ in what value they'd return if the binding would be
>>>>> null
>>>>>>     and perhaps they do a little less boxing/unboxing. Since you can
>>>>> select
>>>>>>     the default value with #orElse which is more flexible. I don't see
>>>>> much
>>>>>>     use to add those variants.
>>>>>>
>>>>>> I agree, I would avoid bloating the primitive specialization classes
>>> for
>>>>>> now, especially when Valhalla is planned to take care of those.
>>>>>
>>>>> Yes, I think we can easily do without for now.
>>>>>
>>>>>>     The ticket is a bit unclear as I can't see what type "x" is.
>>>>>>
>>>>>> Yes, but I got the impression that either way it can be solved with
>>> map
>>>>>> (or flatMap).
>>>>>
>>>>> Agreed.
>>>>>
>>>>> --John
>>>>>
>>>>
>>>
>>
>

From fastegal at openjdk.java.net  Tue Oct  5 13:22:22 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Tue, 5 Oct 2021 13:22:22 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
Message-ID: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>

cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.

Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.

Added/unignored cell tests that are failing/passing before/after the fix.

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

Commit messages:
 - 8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in

Changes: https://git.openjdk.java.net/jfx/pull/638/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8187474
  Stats: 76 lines in 7 files changed: 46 ins; 21 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/638.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/638/head:pull/638

PR: https://git.openjdk.java.net/jfx/pull/638

From kcr at openjdk.java.net  Tue Oct  5 14:04:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 5 Oct 2021 14:04:14 GMT
Subject: RFR: 8272870: Add convenience factory methods for border and
 background [v4]
In-Reply-To: <HBQsnwbObPb0JMyYQtvbyaH4HW38PMHtsEs3Zw_KQZo=.f1e198e0-8492-4bef-bbc8-2b756bd3260e@github.com>
References: <knuGZVSEYvUqgPhBAzgWcK4JM5yLOkbcZNihKRjL--4=.5d2471a8-f9a0-45a3-a38b-4431bd469285@github.com>
 <HBQsnwbObPb0JMyYQtvbyaH4HW38PMHtsEs3Zw_KQZo=.f1e198e0-8492-4bef-bbc8-2b756bd3260e@github.com>
Message-ID: <S-IVnkHfBCx_H1xDV0nf-3YZ3aPkL5py_797j-3iXU8=.62fae6e1-e746-4430-b142-6d07234b69ec@github.com>

On Sun, 19 Sep 2021 01:40:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Added convenience factory factory methods for Background and Border.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added null tests and changed doc as per comments

Looks good. I'll also review the CSR, and then you can Finalize.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/610

From nlisker at gmail.com  Tue Oct  5 15:58:00 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 5 Oct 2021 18:58:00 +0300
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <f265c50d-3496-c67f-e732-c4cdba1ad5bb@xs4all.nl>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <CA+0ynh8Zsw5B6tBQKxG7VzzrQEMj1-YLs1BaLxXyCRFOhY=LPw@mail.gmail.com>
 <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl>
 <CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com>
 <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl>
 <CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com>
 <a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl>
 <CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com>
 <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl>
 <CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com>
 <ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl>
 <CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com>
 <a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl>
 <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
 <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
 <f265c50d-3496-c67f-e732-c4cdba1ad5bb@xs4all.nl>
Message-ID: <CA+0ynh_Mvz3PTBquivNSs3qvYdK5woTeisHZFdOcwDBwijM50w@mail.gmail.com>

Looks good. I assume we will add more bindings in the future like
conditionOn or anything else that I would put under "extras", so maybe the
title could be more specific since there will be more fluent bindings in
the future?

On Tue, Oct 5, 2021 at 1:34 PM John Hendrikx <hjohn at xs4all.nl> wrote:

> I've created https://bugs.openjdk.java.net/browse/JDK-8274771
>
> Please have a look.
>
> --John
>
> On 04/10/2021 17:51, Nir Lisker wrote:
> > I think that a PR can be created. The only point we need to decide is
> about
> > the subscription models we talked about above. ReactFX uses something
> > different for each, you use the same. That can determine if we need
> > different classes for each binding type.
> >
> > I can create the JBS issue for this one and a draft CSR if you want.
> >
> > On Tue, Sep 21, 2021 at 1:36 PM Nir Lisker <nlisker at gmail.com> wrote:
> >
> >> The OrElseBinding is incorrect
> >>>
> >>
> >> Yes, that was a typo with the order of the arguments in the ternary
> >> statement.
> >>
> >> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> >>> think the tests would become pretty unreadable and less useful /
> >>> thourough otherwise).
> >>>
> >>> What are the options?
> >>>
> >>
> >> This is a bigger question. Kevin will have to answer that.
> >>
> >> As for the subscription model: flat map has a more complicated one, but
> >>> orElse, orElseGet and map all have the same one.
> >>>
> >>
> >> From what I saw, ReactFX uses a different subscription model for these.
> I
> >> could have misread it.
> >>
> >> The messages will need to be written from the perspective of the Binding
> >>> class then IMHO.
> >>>
> >>
> >> That's fine.
> >>
> >> As for the Optional methods, I'll have a look in my code base and see if
> >> the places I would like to use them at will become irrelevant anyway
> with
> >> the fluent bindings. I'm fine with proceeding with the current names of
> the
> >> proposed methods.
> >>
> >> On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx <hjohn at xs4all.nl> wrote:
> >>
> >>> I need to get you the tests I wrote, unfortunately, they're JUnit 5,
> >>> please see the tests here:
> >>>
> >>>
> >>>
> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
> >>>
> >>> The OrElseBinding is incorrect, the compute value should read:
> >>>
> >>>      protected T computeValue() {
> >>>        T value = source.getValue();
> >>>        return value == null ? constant : value;
> >>>      }
> >>>
> >>> Similar for OrElseGetBinding.
> >>>
> >>> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
> >>> think the tests would become pretty unreadable and less useful /
> >>> thourough otherwise).
> >>>
> >>> What are the options?
> >>>
> >>> - Integrate a nested runner (there is an Apache 2.0 licensed one
> >>> available)
> >>> - Create our own nested runner (about 200 lines of code)
> >>> - Can we introduce JUnit 5?
> >>> - Rewrite to plain JUnit 4?
> >>>
> >>> Let me know, and I can integrate them.
> >>>
> >>> --John
> >>>
> >>> On 19/09/2021 02:12, Nir Lisker wrote:
> >>>> I've played around with the implementation and pushed a modified
> >>>> prototype to the sandbox [1]. I ended up with something similar to
> >>> ReactFX:
> >>>> the orElse and orElseGet methods have their own binding classes that
> >>>> extend LazyObjectBinding, just like MapBinding and FlatMapBinding. The
> >>>> reason being that both their compute value and their subscription
> models
> >>>> are slightly different. While they can be matched to MapBinding like
> you
> >>>> did, it entails a bit of a roundabout way in my opinion. Creating a
> >>>> supplier for the constant value of orElse somewhat defeats the
> purpose I
> >>>> think.
> >>>
> >>> I have no strong opinion here, just wanted to keep the MR small. The
> >>> supplier should be an inline candidate, but creating a separate class
> is
> >>> fine too.
> >>>
> >>> As for the subscription model: flat map has a more complicated one, but
> >>> orElse, orElseGet and map all have the same one.
> >>>
> >>>> In addition, I think that it's fine to move the arguments' null checks
> >>> to
> >>>> the binding classes themselves, even if it's a couple of levels deeper
> >>> on
> >>>> the stack, while adding a message in the 2nd argument of
> >>>> Objects.requireNonNull for clarity. These classes are "self-contained"
> >>> so
> >>>> it makes sense for them to check their arguments. They might be used
> in
> >>>> other places, perhaps in the public Bindings class.
> >>>
> >>> The messages will need to be written from the perspective of the
> Binding
> >>> class then IMHO.
> >>>
> >>>> I also moved the subscription-related methods from ObservableValue to
> >>>> static methods in Subscription, at least for now, to defer the API
> >>> related
> >>>> to Subscription.
> >>>
> >>> Sounds good.
> >>>
> >>>> The branch doesn't compile because I didn't finish working on the
> >>>> visibility issue, but it's close enough to what I envision it like for
> >>> the
> >>>> first PR.
> >>>
> >>> I've ported the changes over to my branch and ran the tests on it, they
> >>> all pass apart from the above mentioned problem in the OrElse bindings.
> >>>
> >>>> As for the java,util.Optional methods, I indeed did something like
> >>>> `x.orElse(5).getValue()` in the past in other cases, but this approach
> >>>> creates a new binding just to get the wrapped value out, which is very
> >>>> inefficient. (In one case I did booleanValue.isNull().get(), which
> >>> creates
> >>>> a boolean binding, because isPresent() does not exist). I would like
> to
> >>> see
> >>>> what others think about the Optional methods, The binding method
> >>> variants
> >>>> are much more important, but I want to avoid a name clash if the
> >>> Optional
> >>>> ones will have support.
> >>>
> >>> Okay, some more things to consider:
> >>>
> >>> ObservableValue is not an Optional, their get methods respond
> >>> differently with Optional#get throwing an exception when null -- the
> >>> #orElse is a necessity; this is not the case for
> ObservableValue#getValue.
> >>>
> >>> When creating mapping chains, you are going to do this because you want
> >>> to bind this to another property or to listen on it (with subscribe).
> >>> You don't want to do this as a one time thing. If you are creating a
> >>> chain just to calculate a value you can just do this directly. Instead
> of:
> >>>
> >>>      widthProperty().map(x -> x * 2).getValue()
> >>>
> >>> You'd do:
> >>>
> >>>      getWidth() * 2;
> >>>
> >>> With flat mapping however this is not as easy:
> >>>
> >>>      [1]
> >>>      node.sceneProperty()
> >>>        .flatMap(Scene::windowProperty)
> >>>        .flatMap(Window::showingProperty)
> >>>        .orElse(false);
> >>>
> >>> You could try:
> >>>
> >>>      node.getScene().getWindow().isShowing();
> >>>
> >>> But that will not work when Scene or Window is null.  You'd have to
> >>> write it as:
> >>>
> >>>      [2]
> >>>      Optional.ofNullable(node.getScene())
> >>>         .map(Scene::getWindow)
> >>>         .map(Window::isShowing)
> >>>         .orElse(false);
> >>>
> >>> If you only offer a "specialized" orElse, you'd still need to create
> >>> several bindings:
> >>>
> >>>      [3]
> >>>      node.sceneProperty()
> >>>        .flatMap(Scene::windowProperty)
> >>>        .flatMap(Window::showingProperty)
> >>>        .orElse2(false);  // orElse which returns a value not a binding
> >>>
> >>> If you compare [2] (which is possible now) with [3] the difference is
> >>> minimal. A bit more ceremony at the start for [2] but a shorter,
> cleaner
> >>> and faster mapping (no bindings and no need to use the property
> methods).
> >>>
> >>> Now, if you already HAVE the binding for some other purpose, then it is
> >>> highly likely it also already has an #orElse that is needed as part of
> >>> the binding. In that case calling #getValue is fine without much need
> >>> for another #orElse variant.
> >>>
> >>> --John
> >>>
> >>>>
> >>>> [1]
> >>>>
> >>>
> https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
> >>>>
> >>>> On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx <hjohn at xs4all.nl>
> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 15/09/2021 02:28, Nir Lisker wrote:
> >>>>>>     Sorry, I'm not quite sure what you mean by this. Could you
> >>> elaborate?
> >>>>>>     The methods orElse and orElseGet are present in the PoC, and I
> >>> think
> >>>>>>     they're highly useful to have to deal with nulls.
> >>>>>>
> >>>>>>
> >>>>>> The methods that you call orElse and orElseGet return an
> >>>>>> ObservableValue<T>. The Optional methods with the same names return
> >>> the
> >>>>>> wrapped value (of type T). For comparison, ReactFX has:
> >>>>>> T getOrElse(T defaultValue)
> >>>>>> T getOrSupply(Supplier<? extends T> defaultSupplier)
> >>>>>> Val<T> orElseConst(T other)
> >>>>>> Val<T> orElse(ObservableValue<T> other)
> >>>>>
> >>>>> I see what you mean now. The methods from java.util.Optional will
> >>> return
> >>>>> an unwrapped value, while the ones from ObservableValue in the PoC
> >>>>> return an ObservableValue<T>, but they have the same name.
> >>>>>
> >>>>> So java.util.Optional offers:
> >>>>>
> >>>>>      T orElse(T other)
> >>>>>      T orElseGet(Supplier<? extends T> supplier)
> >>>>>
> >>>>> And the PoC:
> >>>>>
> >>>>>      ObservableValue<T> orElse(T alternativeValue)
> >>>>>      ObservableValue<T> orElseGet(Supplier<? extends T> supplier)
> >>>>>
> >>>>> The main difference is in the returned types. Personally, I think it
> is
> >>>>> rarely useful for a binding to be queried directly and I've never
> used
> >>>>> the #getOrElse or #getOrSupply variants that ReactFX offers. On top
> of
> >>>>> that:
> >>>>>
> >>>>>      x.orElse(5).getValue()    ===    x.getOrElse(5)
> >>>>>
> >>>>> So it introduces another method in the interface to avoid having to
> >>>>> write ".getValue()". The opposite, introducing only the "unwrapped"
> >>>>> variants would still require the "wrapped" variants to be present as
> >>> well.
> >>>>>
> >>>>> So, what I would suggest is to not add variants for #getOrElse and
> >>>>> #getOrSupply at all as they are of questionable value and would just
> >>>>> bloat the API for a bit less typing. In that case I think we can
> still
> >>>>> use the signatures as they are.
> >>>>>
> >>>>> ReactFX also offers:
> >>>>>
> >>>>>      Val<T> orElse(ObservableValue<T> other)
> >>>>>
> >>>>> This is another rarely used feature IMHO, and I think Optional#or
> would
> >>>>> a better match for this functionality:
> >>>>>
> >>>>>      Optional<T> or(Supplier<? extends Optional<? extends T>>
> supplier)
> >>>>>
> >>>>> In the POC the signature would be:
> >>>>>
> >>>>>      ObservableValue<T> or(
> >>>>>        Supplier<? extends ObservableValue<? extends T>> supplier
> >>>>>      )
> >>>>>
> >>>>> I didn't implement this one in the PoC to keep it small, but I did
> >>>>> implement this in my JavaFX EventStream library before.
> >>>>>
> >>>>>> So it deals with both getting the wrapped value in null cases and
> with
> >>>>>> getting a "dynamic value" in null cases. I find the Optional-like
> >>> method
> >>>>>> 'T getOrElse(T defaultValue)' useful (along with others such as
> >>>>>> ifPresent because Optional is just useful for dealing with wrapped
> >>>>>> values). What I'm saying is that we should be careful with the names
> >>> if
> >>>>>> we include both "constant" and "dynamic" versions of 'orElse'-like
> >>>>> methods.
> >>>>>
> >>>>> I think #ifPresent can be added, not so sure about the usefulness of
> >>>>> #getOrElse (see above).
> >>>>>
> >>>>>>     The null check in ReactFX's #computeValue is
> >>>>>>     actually checking the result of the mapping function, not
> whether
> >>> the
> >>>>>>     function instance itself was null.
> >>>>>>
> >>>>>> I didn't mean the null-ness of the map argument. What I meant was
> that
> >>>>>> there is this implementation, which is similar to what ReactFX does:
> >>>>>
> >>>>> Sorry, I see it now. You have a good point, the current
> implementation
> >>>>> indeed wraps another Lambda to add the null check which could have
> been
> >>>>> done in #computeValue. I think it would be a good move to avoid the
> >>>>> extra lambda simply because the end result would be more readable --
> >>> any
> >>>>> performance improvement would be a bonus, I don't know if there will
> be
> >>>>> any.
> >>>>>
> >>>>>> As for my points 3 and 4, I'll have to try and play with the
> >>>>>> implementation myself, which will be easier to do when there is some
> >>> PR
> >>>>>> in the works.
> >>>>>
> >>>>> Perhaps this is useful:
> >>>>> https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx
> >>>>>
> >>>>> When you add this as a maven dependency to your project, you will get
> >>>>> the new PoC functionality. It basically uses the Maven shade plugin
> to
> >>>>> replace a few classes in javafx-base -- I use this sometimes to fix
> >>> bugs
> >>>>> I need fixed immediately by patching jfx, but found it also works
> very
> >>>>> nicely to experiment with this PoC.
> >>>>>
> >>>>> Also, the PoC PR compiles fine, it may need rebasing.
> >>>>>
> >>>>>>     To close "Bindings.select*(): add new type-safe template based
> API
> >>>>>>     instead of legacy-style set of methods" we'd need the
> >>> flatMap/select
> >>>>>>     method to be included.
> >>>>>>
> >>>>>> Yes. I think that we can include flatMap in this iteration, perhaps
> as
> >>>>>> a separate PR?
> >>>>>
> >>>>> That should be no problem, I can split it up.
> >>>>>
> >>>>>>     I don't think we really need specialized methods for primitives
> >>> (or
> >>>>> at
> >>>>>>     least, not right away).  At this point the primitive versions
> only
> >>>>>>     really differ in what value they'd return if the binding would
> be
> >>>>> null
> >>>>>>     and perhaps they do a little less boxing/unboxing. Since you can
> >>>>> select
> >>>>>>     the default value with #orElse which is more flexible. I don't
> see
> >>>>> much
> >>>>>>     use to add those variants.
> >>>>>>
> >>>>>> I agree, I would avoid bloating the primitive specialization classes
> >>> for
> >>>>>> now, especially when Valhalla is planned to take care of those.
> >>>>>
> >>>>> Yes, I think we can easily do without for now.
> >>>>>
> >>>>>>     The ticket is a bit unclear as I can't see what type "x" is.
> >>>>>>
> >>>>>> Yes, but I got the impression that either way it can be solved with
> >>> map
> >>>>>> (or flatMap).
> >>>>>
> >>>>> Agreed.
> >>>>>
> >>>>> --John
> >>>>>
> >>>>
> >>>
> >>
> >
>

From arapte at openjdk.java.net  Tue Oct  5 17:40:11 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Tue, 5 Oct 2021 17:40:11 GMT
Subject: RFR: 8272870: Add convenience factory methods for border and
 background [v4]
In-Reply-To: <HBQsnwbObPb0JMyYQtvbyaH4HW38PMHtsEs3Zw_KQZo=.f1e198e0-8492-4bef-bbc8-2b756bd3260e@github.com>
References: <knuGZVSEYvUqgPhBAzgWcK4JM5yLOkbcZNihKRjL--4=.5d2471a8-f9a0-45a3-a38b-4431bd469285@github.com>
 <HBQsnwbObPb0JMyYQtvbyaH4HW38PMHtsEs3Zw_KQZo=.f1e198e0-8492-4bef-bbc8-2b756bd3260e@github.com>
Message-ID: <yShCXlhzj8j6PVCF1QPNow-xUnT9a_jm4RfGTLQrwOU=.5c4c6499-dfae-4c3b-8277-417043801aef@github.com>

On Sun, 19 Sep 2021 01:40:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Added convenience factory factory methods for Background and Border.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added null tests and changed doc as per comments

Marked as reviewed by arapte (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/610

From github.com+12087024+beldenfox at openjdk.java.net  Tue Oct  5 20:41:27 2021
From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox)
Date: Tue, 5 Oct 2021 20:41:27 GMT
Subject: RFR: 8232812: [MacOS] Double click title bar does not restore window
 size
Message-ID: <qr_SAt3FHWg3aC0hK35MCDI3aneS8lCz1D77cSME130=.705c963f-a83c-4ae7-8971-798ac2171bab@github.com>

The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8163137 in a slightly different way.

Access to the zoom/unzoom feature has changed with newer versions of macOS. To reproduce this you have to change `System Preferences > Dock & Menu Bar > Double-click a window's title bar` to `zoom`. Then use double-clicks in the title bar to test the feature. The green button in the title bar no longer has anything to do with zoom/unzoom.

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

Commit messages:
 - Unzooming windows using double-clicks works again.

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

PR: https://git.openjdk.java.net/jfx/pull/639

From hjohn at xs4all.nl  Tue Oct  5 20:59:53 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Tue, 5 Oct 2021 22:59:53 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <CA+0ynh_Mvz3PTBquivNSs3qvYdK5woTeisHZFdOcwDBwijM50w@mail.gmail.com>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
 <4ef2aa29-afb3-704c-bcb1-9a58f674e1fb@xs4all.nl>
 <CA+0ynh-fggF+JouWQ0X6HiJkqko2rcvHwfD0SD4ZYdKfNB=Yvg@mail.gmail.com>
 <7836a846-65eb-63e3-d8c9-d7bb9617cfbb@xs4all.nl>
 <CA+0ynh_jQ4COjtEyO8gr++E7mQD5Vakw9OabNe+QvnEDqFM66Q@mail.gmail.com>
 <a72fc186-7d16-1051-f0c2-cd742dcf2638@xs4all.nl>
 <CA+0ynh85m1GXePxmBZiK2Osfjyq+EF7dc3dRkg1aTK-AE18LLQ@mail.gmail.com>
 <186e3394-633e-582c-f2ac-f68b6374d891@xs4all.nl>
 <CA+0ynh_b_Y76QR+5=2YLKq_9uEttC71C+dw2g34D6URnHw-k5Q@mail.gmail.com>
 <ca54edd4-fa6c-ac18-1151-c61a2ba2fdda@xs4all.nl>
 <CA+0ynh-wxTOhMx+=CNHM01kui3CHMzyGrfLOACYcNsXZpOc+Cw@mail.gmail.com>
 <a7614cfc-e828-0f7e-c6c9-21a05cea2b63@xs4all.nl>
 <CA+0ynh9oja_NjW5__jYymWy51iAxO1SHUwT+w_LrqW2QjzyfUA@mail.gmail.com>
 <CA+0ynh8rWgCsVPO7RmqSJzNpXoVvd+Ki612=T+L=k+KccJxyPA@mail.gmail.com>
 <f265c50d-3496-c67f-e732-c4cdba1ad5bb@xs4all.nl>
 <CA+0ynh_Mvz3PTBquivNSs3qvYdK5woTeisHZFdOcwDBwijM50w@mail.gmail.com>
Message-ID: <35f44f0c-83b5-937b-a59f-a97ad55f0068@xs4all.nl>

I made the title more specific :)

--John

On 05/10/2021 17:58, Nir Lisker wrote:
> Looks good. I assume we will add more bindings in the future like
> conditionOn or anything else that I would put under "extras", so maybe
> the title could be more specific since there will be more fluent
> bindings in the future?
>
> On Tue, Oct 5, 2021 at 1:34 PM John Hendrikx <hjohn at xs4all.nl
> <mailto:hjohn at xs4all.nl>> wrote:
>
>     I've created https://bugs.openjdk.java.net/browse/JDK-8274771
>
>     Please have a look.
>
>     --John
>
>     On 04/10/2021 17:51, Nir Lisker wrote:
>     > I think that a PR can be created. The only point we need to decide
>     is about
>     > the subscription models we talked about above. ReactFX uses something
>     > different for each, you use the same. That can determine if we need
>     > different classes for each binding type.
>     >
>     > I can create the JBS issue for this one and a draft CSR if you want.
>     >
>     > On Tue, Sep 21, 2021 at 1:36 PM Nir Lisker <nlisker at gmail.com
>     <mailto:nlisker at gmail.com>> wrote:
>     >
>     >> The OrElseBinding is incorrect
>     >>>
>     >>
>     >> Yes, that was a typo with the order of the arguments in the ternary
>     >> statement.
>     >>
>     >> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>     >>> think the tests would become pretty unreadable and less useful /
>     >>> thourough otherwise).
>     >>>
>     >>> What are the options?
>     >>>
>     >>
>     >> This is a bigger question. Kevin will have to answer that.
>     >>
>     >> As for the subscription model: flat map has a more complicated
>     one, but
>     >>> orElse, orElseGet and map all have the same one.
>     >>>
>     >>
>     >> From what I saw, ReactFX uses a different subscription model for
>     these. I
>     >> could have misread it.
>     >>
>     >> The messages will need to be written from the perspective of the
>     Binding
>     >>> class then IMHO.
>     >>>
>     >>
>     >> That's fine.
>     >>
>     >> As for the Optional methods, I'll have a look in my code base and
>     see if
>     >> the places I would like to use them at will become irrelevant
>     anyway with
>     >> the fluent bindings. I'm fine with proceeding with the current
>     names of the
>     >> proposed methods.
>     >>
>     >> On Sun, Sep 19, 2021 at 6:12 PM John Hendrikx <hjohn at xs4all.nl
>     <mailto:hjohn at xs4all.nl>> wrote:
>     >>
>     >>> I need to get you the tests I wrote, unfortunately, they're JUnit 5,
>     >>> please see the tests here:
>     >>>
>     >>>
>     >>>
>     https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx/src/test/java/javafx/beans/value
>     >>>
>     >>> The OrElseBinding is incorrect, the compute value should read:
>     >>>
>     >>>      protected T computeValue() {
>     >>>        T value = source.getValue();
>     >>>        return value == null ? constant : value;
>     >>>      }
>     >>>
>     >>> Similar for OrElseGetBinding.
>     >>>
>     >>> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
>     >>> think the tests would become pretty unreadable and less useful /
>     >>> thourough otherwise).
>     >>>
>     >>> What are the options?
>     >>>
>     >>> - Integrate a nested runner (there is an Apache 2.0 licensed one
>     >>> available)
>     >>> - Create our own nested runner (about 200 lines of code)
>     >>> - Can we introduce JUnit 5?
>     >>> - Rewrite to plain JUnit 4?
>     >>>
>     >>> Let me know, and I can integrate them.
>     >>>
>     >>> --John
>     >>>
>     >>> On 19/09/2021 02:12, Nir Lisker wrote:
>     >>>> I've played around with the implementation and pushed a modified
>     >>>> prototype to the sandbox [1]. I ended up with something similar to
>     >>> ReactFX:
>     >>>> the orElse and orElseGet methods have their own binding classes
>     that
>     >>>> extend LazyObjectBinding, just like MapBinding and
>     FlatMapBinding. The
>     >>>> reason being that both their compute value and their
>     subscription models
>     >>>> are slightly different. While they can be matched to MapBinding
>     like you
>     >>>> did, it entails a bit of a roundabout way in my opinion. Creating a
>     >>>> supplier for the constant value of orElse somewhat defeats the
>     purpose I
>     >>>> think.
>     >>>
>     >>> I have no strong opinion here, just wanted to keep the MR small. The
>     >>> supplier should be an inline candidate, but creating a separate
>     class is
>     >>> fine too.
>     >>>
>     >>> As for the subscription model: flat map has a more complicated
>     one, but
>     >>> orElse, orElseGet and map all have the same one.
>     >>>
>     >>>> In addition, I think that it's fine to move the arguments' null
>     checks
>     >>> to
>     >>>> the binding classes themselves, even if it's a couple of levels
>     deeper
>     >>> on
>     >>>> the stack, while adding a message in the 2nd argument of
>     >>>> Objects.requireNonNull for clarity. These classes are
>     "self-contained"
>     >>> so
>     >>>> it makes sense for them to check their arguments. They might be
>     used in
>     >>>> other places, perhaps in the public Bindings class.
>     >>>
>     >>> The messages will need to be written from the perspective of the
>     Binding
>     >>> class then IMHO.
>     >>>
>     >>>> I also moved the subscription-related methods from
>     ObservableValue to
>     >>>> static methods in Subscription, at least for now, to defer the API
>     >>> related
>     >>>> to Subscription.
>     >>>
>     >>> Sounds good.
>     >>>
>     >>>> The branch doesn't compile because I didn't finish working on the
>     >>>> visibility issue, but it's close enough to what I envision it
>     like for
>     >>> the
>     >>>> first PR.
>     >>>
>     >>> I've ported the changes over to my branch and ran the tests on
>     it, they
>     >>> all pass apart from the above mentioned problem in the OrElse
>     bindings.
>     >>>
>     >>>> As for the java,util.Optional methods, I indeed did something like
>     >>>> `x.orElse(5).getValue()` in the past in other cases, but this
>     approach
>     >>>> creates a new binding just to get the wrapped value out, which
>     is very
>     >>>> inefficient. (In one case I did booleanValue.isNull().get(), which
>     >>> creates
>     >>>> a boolean binding, because isPresent() does not exist). I would
>     like to
>     >>> see
>     >>>> what others think about the Optional methods, The binding method
>     >>> variants
>     >>>> are much more important, but I want to avoid a name clash if the
>     >>> Optional
>     >>>> ones will have support.
>     >>>
>     >>> Okay, some more things to consider:
>     >>>
>     >>> ObservableValue is not an Optional, their get methods respond
>     >>> differently with Optional#get throwing an exception when null -- the
>     >>> #orElse is a necessity; this is not the case for
>     ObservableValue#getValue.
>     >>>
>     >>> When creating mapping chains, you are going to do this because
>     you want
>     >>> to bind this to another property or to listen on it (with
>     subscribe).
>     >>> You don't want to do this as a one time thing. If you are creating a
>     >>> chain just to calculate a value you can just do this directly.
>     Instead of:
>     >>>
>     >>>      widthProperty().map(x -> x * 2).getValue()
>     >>>
>     >>> You'd do:
>     >>>
>     >>>      getWidth() * 2;
>     >>>
>     >>> With flat mapping however this is not as easy:
>     >>>
>     >>>      [1]
>     >>>      node.sceneProperty()
>     >>>        .flatMap(Scene::windowProperty)
>     >>>        .flatMap(Window::showingProperty)
>     >>>        .orElse(false);
>     >>>
>     >>> You could try:
>     >>>
>     >>>      node.getScene().getWindow().isShowing();
>     >>>
>     >>> But that will not work when Scene or Window is null.  You'd have to
>     >>> write it as:
>     >>>
>     >>>      [2]
>     >>>      Optional.ofNullable(node.getScene())
>     >>>         .map(Scene::getWindow)
>     >>>         .map(Window::isShowing)
>     >>>         .orElse(false);
>     >>>
>     >>> If you only offer a "specialized" orElse, you'd still need to create
>     >>> several bindings:
>     >>>
>     >>>      [3]
>     >>>      node.sceneProperty()
>     >>>        .flatMap(Scene::windowProperty)
>     >>>        .flatMap(Window::showingProperty)
>     >>>        .orElse2(false);  // orElse which returns a value not a
>     binding
>     >>>
>     >>> If you compare [2] (which is possible now) with [3] the
>     difference is
>     >>> minimal. A bit more ceremony at the start for [2] but a shorter,
>     cleaner
>     >>> and faster mapping (no bindings and no need to use the property
>     methods).
>     >>>
>     >>> Now, if you already HAVE the binding for some other purpose,
>     then it is
>     >>> highly likely it also already has an #orElse that is needed as
>     part of
>     >>> the binding. In that case calling #getValue is fine without much
>     need
>     >>> for another #orElse variant.
>     >>>
>     >>> --John
>     >>>
>     >>>>
>     >>>> [1]
>     >>>>
>     >>>
>     https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
>     >>>>
>     >>>> On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx <hjohn at xs4all.nl
>     <mailto:hjohn at xs4all.nl>> wrote:
>     >>>>
>     >>>>>
>     >>>>>
>     >>>>> On 15/09/2021 02:28, Nir Lisker wrote:
>     >>>>>>     Sorry, I'm not quite sure what you mean by this. Could you
>     >>> elaborate?
>     >>>>>>     The methods orElse and orElseGet are present in the PoC,
>     and I
>     >>> think
>     >>>>>>     they're highly useful to have to deal with nulls.
>     >>>>>>
>     >>>>>>
>     >>>>>> The methods that you call orElse and orElseGet return an
>     >>>>>> ObservableValue<T>. The Optional methods with the same names
>     return
>     >>> the
>     >>>>>> wrapped value (of type T). For comparison, ReactFX has:
>     >>>>>> T getOrElse(T defaultValue)
>     >>>>>> T getOrSupply(Supplier<? extends T> defaultSupplier)
>     >>>>>> Val<T> orElseConst(T other)
>     >>>>>> Val<T> orElse(ObservableValue<T> other)
>     >>>>>
>     >>>>> I see what you mean now. The methods from java.util.Optional will
>     >>> return
>     >>>>> an unwrapped value, while the ones from ObservableValue in the PoC
>     >>>>> return an ObservableValue<T>, but they have the same name.
>     >>>>>
>     >>>>> So java.util.Optional offers:
>     >>>>>
>     >>>>>      T orElse(T other)
>     >>>>>      T orElseGet(Supplier<? extends T> supplier)
>     >>>>>
>     >>>>> And the PoC:
>     >>>>>
>     >>>>>      ObservableValue<T> orElse(T alternativeValue)
>     >>>>>      ObservableValue<T> orElseGet(Supplier<? extends T> supplier)
>     >>>>>
>     >>>>> The main difference is in the returned types. Personally, I
>     think it is
>     >>>>> rarely useful for a binding to be queried directly and I've
>     never used
>     >>>>> the #getOrElse or #getOrSupply variants that ReactFX offers.
>     On top of
>     >>>>> that:
>     >>>>>
>     >>>>>      x.orElse(5).getValue()    ===    x.getOrElse(5)
>     >>>>>
>     >>>>> So it introduces another method in the interface to avoid
>     having to
>     >>>>> write ".getValue()". The opposite, introducing only the
>     "unwrapped"
>     >>>>> variants would still require the "wrapped" variants to be
>     present as
>     >>> well.
>     >>>>>
>     >>>>> So, what I would suggest is to not add variants for #getOrElse and
>     >>>>> #getOrSupply at all as they are of questionable value and
>     would just
>     >>>>> bloat the API for a bit less typing. In that case I think we
>     can still
>     >>>>> use the signatures as they are.
>     >>>>>
>     >>>>> ReactFX also offers:
>     >>>>>
>     >>>>>      Val<T> orElse(ObservableValue<T> other)
>     >>>>>
>     >>>>> This is another rarely used feature IMHO, and I think
>     Optional#or would
>     >>>>> a better match for this functionality:
>     >>>>>
>     >>>>>      Optional<T> or(Supplier<? extends Optional<? extends T>>
>     supplier)
>     >>>>>
>     >>>>> In the POC the signature would be:
>     >>>>>
>     >>>>>      ObservableValue<T> or(
>     >>>>>        Supplier<? extends ObservableValue<? extends T>> supplier
>     >>>>>      )
>     >>>>>
>     >>>>> I didn't implement this one in the PoC to keep it small, but I did
>     >>>>> implement this in my JavaFX EventStream library before.
>     >>>>>
>     >>>>>> So it deals with both getting the wrapped value in null cases
>     and with
>     >>>>>> getting a "dynamic value" in null cases. I find the Optional-like
>     >>> method
>     >>>>>> 'T getOrElse(T defaultValue)' useful (along with others such as
>     >>>>>> ifPresent because Optional is just useful for dealing with
>     wrapped
>     >>>>>> values). What I'm saying is that we should be careful with
>     the names
>     >>> if
>     >>>>>> we include both "constant" and "dynamic" versions of
>     'orElse'-like
>     >>>>> methods.
>     >>>>>
>     >>>>> I think #ifPresent can be added, not so sure about the
>     usefulness of
>     >>>>> #getOrElse (see above).
>     >>>>>
>     >>>>>>     The null check in ReactFX's #computeValue is
>     >>>>>>     actually checking the result of the mapping function, not
>     whether
>     >>> the
>     >>>>>>     function instance itself was null.
>     >>>>>>
>     >>>>>> I didn't mean the null-ness of the map argument. What I meant
>     was that
>     >>>>>> there is this implementation, which is similar to what
>     ReactFX does:
>     >>>>>
>     >>>>> Sorry, I see it now. You have a good point, the current
>     implementation
>     >>>>> indeed wraps another Lambda to add the null check which could
>     have been
>     >>>>> done in #computeValue. I think it would be a good move to
>     avoid the
>     >>>>> extra lambda simply because the end result would be more
>     readable --
>     >>> any
>     >>>>> performance improvement would be a bonus, I don't know if
>     there will be
>     >>>>> any.
>     >>>>>
>     >>>>>> As for my points 3 and 4, I'll have to try and play with the
>     >>>>>> implementation myself, which will be easier to do when there
>     is some
>     >>> PR
>     >>>>>> in the works.
>     >>>>>
>     >>>>> Perhaps this is useful:
>     >>>>>
>     https://github.com/hjohn/MediaSystem-v2/tree/master/mediasystem-jfx
>     >>>>>
>     >>>>> When you add this as a maven dependency to your project, you
>     will get
>     >>>>> the new PoC functionality. It basically uses the Maven shade
>     plugin to
>     >>>>> replace a few classes in javafx-base -- I use this sometimes
>     to fix
>     >>> bugs
>     >>>>> I need fixed immediately by patching jfx, but found it also
>     works very
>     >>>>> nicely to experiment with this PoC.
>     >>>>>
>     >>>>> Also, the PoC PR compiles fine, it may need rebasing.
>     >>>>>
>     >>>>>>     To close "Bindings.select*(): add new type-safe template
>     based API
>     >>>>>>     instead of legacy-style set of methods" we'd need the
>     >>> flatMap/select
>     >>>>>>     method to be included.
>     >>>>>>
>     >>>>>> Yes. I think that we can include flatMap in this iteration,
>     perhaps as
>     >>>>>> a separate PR?
>     >>>>>
>     >>>>> That should be no problem, I can split it up.
>     >>>>>
>     >>>>>>     I don't think we really need specialized methods for
>     primitives
>     >>> (or
>     >>>>> at
>     >>>>>>     least, not right away).  At this point the primitive
>     versions only
>     >>>>>>     really differ in what value they'd return if the binding
>     would be
>     >>>>> null
>     >>>>>>     and perhaps they do a little less boxing/unboxing. Since
>     you can
>     >>>>> select
>     >>>>>>     the default value with #orElse which is more flexible. I
>     don't see
>     >>>>> much
>     >>>>>>     use to add those variants.
>     >>>>>>
>     >>>>>> I agree, I would avoid bloating the primitive specialization
>     classes
>     >>> for
>     >>>>>> now, especially when Valhalla is planned to take care of those.
>     >>>>>
>     >>>>> Yes, I think we can easily do without for now.
>     >>>>>
>     >>>>>>     The ticket is a bit unclear as I can't see what type "x" is.
>     >>>>>>
>     >>>>>> Yes, but I got the impression that either way it can be
>     solved with
>     >>> map
>     >>>>>> (or flatMap).
>     >>>>>
>     >>>>> Agreed.
>     >>>>>
>     >>>>> --John
>     >>>>>
>     >>>>
>     >>>
>     >>
>     >
>

From mstrauss at openjdk.java.net  Tue Oct  5 22:05:18 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Tue, 5 Oct 2021 22:05:18 GMT
Subject: RFR: 8268225: Support :focus-visible and :focus-within CSS
 pseudoclasses [v7]
In-Reply-To: <vp_Ez2FbsWiwcuNkE8ZCt-hjuT6fTzy5UXBkleogPRg=.f58775fa-39ce-40a9-9310-040551ea661a@github.com>
References: <icGk3ZoqUqkxHyAN_wAJQTEDNCmBL0J5xcSGzr1FEM8=.89f28a52-2b6e-45de-815a-ec2665c4f441@github.com>
 <vp_Ez2FbsWiwcuNkE8ZCt-hjuT6fTzy5UXBkleogPRg=.f58775fa-39ce-40a9-9310-040551ea661a@github.com>
Message-ID: <_uFI9kM_NZu3CcnjF7soQLlotCUdbG5ckJ1I-3y9CRg=.604d194a-ae29-47d2-a97f-4a41eea3a734@github.com>

On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as well as the corresponding `:focus-visible` and `:focus-within` CSS pseudo-classes.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed undeterministic test failures

I've created a [CSR](https://bugs.openjdk.java.net/browse/JDK-8274798) for this feature.

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

PR: https://git.openjdk.java.net/jfx/pull/475

From thiago.sayao at gmail.com  Tue Oct  5 22:40:09 2021
From: thiago.sayao at gmail.com (=?UTF-8?Q?Thiago_Milczarek_Say=C3=A3o?=)
Date: Tue, 5 Oct 2021 19:40:09 -0300
Subject: Gtk4 on openjfx-sandbox
Message-ID: <CAAP_wum3La2hwf-3Y=KQ_SnmtK+n=rSik66X9BkFjG8LmFCoUg@mail.gmail.com>

Hi,

I have done some porting to gtk4:

https://github.com/openjdk/jfx-sandbox/tree/tsayao_gtk4_playground

It currently compiles, but does not show any windows (I suspect of an
threading issue). Some parts such as DND are commented out.

To use it, pass: -Djdk.gtk.version=4 -Djdk.gtk.verbose=true

-- Thiago.

From kevin.rushforth at oracle.com  Wed Oct  6 00:15:28 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Tue, 5 Oct 2021 17:15:28 -0700
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
Message-ID: <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>

Given that the intention of InvalidationListener was to be a 
light-weight way to listen to properties without causing a binding chain 
to be revalidated, it does seem reasonable to me that the listener is 
only fired on the valid --> invalid transition, which is the specified 
behavior, even if the implementation doesn't currently do that in all cases.

The two related questions then are:

1. Should adding an invalidation listener to property do an immediate 
get(), which will ensure that the property is then valid? This will 
force an eager evaluation of the property and "arm" the property to fire 
an invalidation even the next time it is invalidated.

2. Should adding an invalidation listener to a currently invalid 
property cause the listener to be called (either immediately or the next 
time the object is invalidated)?

I think the ideal answer to both questions is "no", although I share 
John's concern that changing this behavior for InvalidationListeners 
could break applications. So the question is: how likely do we think 
that changing this behavior will break existing applications?

I think it's something we can and should consider changing. Unless there 
are serious concerns, I would support changing this behavior as part of 
avoiding eager evaluation when using invalidation listeners. It would 
need to be well tested (of course), and would need a CSR describing the 
compatibility risk, and should probably get a release note.

Any concerns in doing this?

On the related question, I like the idea of nulling out the current 
value when a property is bound.

-- Kevin


On 9/11/2021 9:41 AM, Nir Lisker wrote:
> I think that we need your input on this to move it forward.
>
> On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com 
> <mailto:nlisker at gmail.com>> wrote:
>
>         so the value field should perhaps be nulled out when bound.
>
>
>     There was a PR for something like that in the old repo:
>     https://github.com/javafxports/openjdk-jfx/pull/110
>     <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
>
>     On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl
>     <mailto:hjohn at xs4all.nl>> wrote:
>
>
>
>         On 02/09/2021 11:57, Nir Lisker wrote:
>         >? ? ?So in order
>         >? ? ?to make sure that a new interested invalidation listener
>         does not miss
>         >? ? ?the fact that a property was *already* invalid, the
>         easiest solution
>         >? ? ?might have been to revalidate it upon registration of a
>         new listener
>         >
>         >
>         > But why does an invalidation listener need to know the past
>         state of the
>         > property? It is only interested in the valid -> invalid
>         transition. If
>         > the property was invalid then the listener (in theory)
>         shouldn't receive
>         > any events anyway on subsequent invalidations. (I understand
>         that you
>         > don't justify this, I'm posing it as a general question.)
>
>         Strictly speaking, no, if users are using InvalidationListener
>         correctly
>         then this is definitely correct behavior. I'm not really
>         advocating a
>         change, and I'd even prefer that it be brought in line with the
>         documentation.
>
>         I think however that many users are not using it correctly and
>         expect an
>         invalidation event always the next time the value changes (and
>         their
>         listener will read that value, validating it again), making it
>         act like
>         a light-weight ChangeListener. I know that I probably have
>         written code
>         that made that assumption, and would in the past not even
>         think twice
>         about replacing a change with an invalidation listener or vice
>         versa if
>         that happened to be a better fit. Which is sort of what
>         happened as well
>         in the bidirectional binding PR, and the issue slipped past
>         the author
>         and two reviewers.
>
>         > I suggest that we split the problem into 2: one is the case
>         where the
>         > property was valid when the listener was attached, and the
>         other is when
>         > it was invalid.
>         > * A valid starting state. In this case attaching a listener
>         shouldn't
>         > need to do anything. A subsequent invalidation event will be
>         sent
>         > regardless. Currently, it is calling get() redundantly.
>
>         True, the call to get is redundant in this case. Ugly too,
>         calling get
>         and discarding its result, while the intention is to force the
>         property
>         to become valid.
>
>         > * An invalid starting state. In this case the documentation
>         says that
>         > nothing needs to happen, but get() is called anyway. Here, the
>         > difference is that a subsequent invalidation event is sent
>         in one case
>         > and not in the other. The only way to advance here is to
>         make a design
>         > decision on what should happen, at least that's how I see it.
>
>         The docs are even more specific I think, they say no more
>         events will be
>         generated until it becomes valid -- it doesn't leave any
>         option open
>         that it could generate events if it wanted to.
>
>         > As to the implementation of a possible solution, suppose we
>         add the
>         > isValid method. Upon attaching an invalidation listener, if
>         the property
>         > is valid, we can skip the get() call. That solves the valid
>         starting
>         > state issue. The question is what to do if the property is
>         not valid.
>         >
>         > I also noticed an odd design choice in the implementation of
>         properties:
>         > the value field does not update if the property is bound,
>         instead, the
>         > result of the binding is returned and the value field holds
>         an outdated
>         > value (until the property is unbound).
>
>         Yeah, that might not be a wise decision as that can lead to
>         memory being
>         referenced that users might expect to be freed. I didn't see
>         anywhere
>         defined what will happen to the value of the property when it
>         is unbound
>         again. The current implementation will keep its last value
>         (during the
>         unbind it will take the last value and assign it to its own value
>         field), so the value field should perhaps be nulled out when
>         bound.
>
>         --John
>


From nlisker at gmail.com  Wed Oct  6 02:38:48 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 6 Oct 2021 05:38:48 +0300
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
Message-ID: <CA+0ynh_U041DJvUpFTwf4vNJ9SP29VGQ2=2U5rvHTXjApkLcNg@mail.gmail.com>

I would also answer "no" to both points. This is also what the docs say.

So the question is: how likely do we think that changing this behavior will
> break existing applications?
>

That's the main question. I tested the JavaFX code with the new behavior
and some tests break immediately, though a few I've looked at seemed to be
testing the invalidation listener behavior itself (in their own context). I
don't know what would break outside of the tests. If we go this route, we
might want to create PRs to fix the tests before we actually change
the behavior (in contrast to doing it all in the same PR). I think that
tests fail in several modules and it might require several people to fix
these tests depending on their areas of expertise. Then we would need to
test runtime behavior to see what breaks outside of the tests.

In my own codebase nothing breaks, but it's relatively small.

On the related question, I like the idea of nulling out the current value
> when a property is bound.
>

I can pick up from where the older PR stopped. It's a simple change.

On Wed, Oct 6, 2021 at 3:15 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Given that the intention of InvalidationListener was to be a light-weight
> way to listen to properties without causing a binding chain to be
> revalidated, it does seem reasonable to me that the listener is only fired
> on the valid --> invalid transition, which is the specified behavior, even
> if the implementation doesn't currently do that in all cases.
>
> The two related questions then are:
>
> 1. Should adding an invalidation listener to property do an immediate
> get(), which will ensure that the property is then valid? This will force
> an eager evaluation of the property and "arm" the property to fire an
> invalidation even the next time it is invalidated.
>
> 2. Should adding an invalidation listener to a currently invalid property
> cause the listener to be called (either immediately or the next time the
> object is invalidated)?
>
> I think the ideal answer to both questions is "no", although I share
> John's concern that changing this behavior for InvalidationListeners could
> break applications. So the question is: how likely do we think that
> changing this behavior will break existing applications?
>
> I think it's something we can and should consider changing. Unless there
> are serious concerns, I would support changing this behavior as part of
> avoiding eager evaluation when using invalidation listeners. It would need
> to be well tested (of course), and would need a CSR describing the
> compatibility risk, and should probably get a release note.
>
> Any concerns in doing this?
>
> On the related question, I like the idea of nulling out the current value
> when a property is bound.
>
> -- Kevin
>
>
> On 9/11/2021 9:41 AM, Nir Lisker wrote:
>
> I think that we need your input on this to move it forward.
>
> On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> so the value field should perhaps be nulled out when bound.
>>
>>
>> There was a PR for something like that in the old repo:
>> https://github.com/javafxports/openjdk-jfx/pull/110
>> <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
>>
>> On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl> wrote:
>>
>>>
>>>
>>> On 02/09/2021 11:57, Nir Lisker wrote:
>>> >     So in order
>>> >     to make sure that a new interested invalidation listener does not
>>> miss
>>> >     the fact that a property was *already* invalid, the easiest
>>> solution
>>> >     might have been to revalidate it upon registration of a new
>>> listener
>>> >
>>> >
>>> > But why does an invalidation listener need to know the past state of
>>> the
>>> > property? It is only interested in the valid -> invalid transition. If
>>> > the property was invalid then the listener (in theory) shouldn't
>>> receive
>>> > any events anyway on subsequent invalidations. (I understand that you
>>> > don't justify this, I'm posing it as a general question.)
>>>
>>> Strictly speaking, no, if users are using InvalidationListener correctly
>>> then this is definitely correct behavior. I'm not really advocating a
>>> change, and I'd even prefer that it be brought in line with the
>>> documentation.
>>>
>>> I think however that many users are not using it correctly and expect an
>>> invalidation event always the next time the value changes (and their
>>> listener will read that value, validating it again), making it act like
>>> a light-weight ChangeListener. I know that I probably have written code
>>> that made that assumption, and would in the past not even think twice
>>> about replacing a change with an invalidation listener or vice versa if
>>> that happened to be a better fit. Which is sort of what happened as well
>>> in the bidirectional binding PR, and the issue slipped past the author
>>> and two reviewers.
>>>
>>> > I suggest that we split the problem into 2: one is the case where the
>>> > property was valid when the listener was attached, and the other is
>>> when
>>> > it was invalid.
>>> > * A valid starting state. In this case attaching a listener shouldn't
>>> > need to do anything. A subsequent invalidation event will be sent
>>> > regardless. Currently, it is calling get() redundantly.
>>>
>>> True, the call to get is redundant in this case. Ugly too, calling get
>>> and discarding its result, while the intention is to force the property
>>> to become valid.
>>>
>>> > * An invalid starting state. In this case the documentation says that
>>> > nothing needs to happen, but get() is called anyway. Here, the
>>> > difference is that a subsequent invalidation event is sent in one case
>>> > and not in the other. The only way to advance here is to make a design
>>> > decision on what should happen, at least that's how I see it.
>>>
>>> The docs are even more specific I think, they say no more events will be
>>> generated until it becomes valid -- it doesn't leave any option open
>>> that it could generate events if it wanted to.
>>>
>>> > As to the implementation of a possible solution, suppose we add the
>>> > isValid method. Upon attaching an invalidation listener, if the
>>> property
>>> > is valid, we can skip the get() call. That solves the valid starting
>>> > state issue. The question is what to do if the property is not valid.
>>> >
>>> > I also noticed an odd design choice in the implementation of
>>> properties:
>>> > the value field does not update if the property is bound, instead, the
>>> > result of the binding is returned and the value field holds an outdated
>>> > value (until the property is unbound).
>>>
>>> Yeah, that might not be a wise decision as that can lead to memory being
>>> referenced that users might expect to be freed. I didn't see anywhere
>>> defined what will happen to the value of the property when it is unbound
>>> again. The current implementation will keep its last value (during the
>>> unbind it will take the last value and assign it to its own value
>>> field), so the value field should perhaps be nulled out when bound.
>>>
>>> --John
>>>
>>
>

From hjohn at xs4all.nl  Wed Oct  6 07:39:16 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Wed, 6 Oct 2021 09:39:16 +0200
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <CA+0ynh_U041DJvUpFTwf4vNJ9SP29VGQ2=2U5rvHTXjApkLcNg@mail.gmail.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CA+0ynh_U041DJvUpFTwf4vNJ9SP29VGQ2=2U5rvHTXjApkLcNg@mail.gmail.com>
Message-ID: <63151262-feed-c406-7165-7a3c08bc0183@xs4all.nl>

Is it possible to dig in the history of ExpressionHelper a bit further? 
In git it seems limited to 9 years ago, but in JIRA I found this bug report:

     https://bugs.openjdk.java.net/browse/JDK-8119521

It describes an issue where an InvalidationListener is not working 
correctly (according to the reporter) and where #get must be called to 
make it behave as expected.  But it turns out this was already fixed -- 
this specific fix might have been the one that introduced the #get call 
in ExpressionHelper.

On 06/10/2021 04:38, Nir Lisker wrote:
> I would also answer "no" to both points. This is also what the docs say.
>
> So the question is: how likely do we think that changing this behavior will
>> break existing applications?
>>
>
> That's the main question. I tested the JavaFX code with the new behavior
> and some tests break immediately, though a few I've looked at seemed to be
> testing the invalidation listener behavior itself (in their own context). I
> don't know what would break outside of the tests. If we go this route, we
> might want to create PRs to fix the tests before we actually change
> the behavior (in contrast to doing it all in the same PR). I think that
> tests fail in several modules and it might require several people to fix
> these tests depending on their areas of expertise. Then we would need to
> test runtime behavior to see what breaks outside of the tests.
>
> In my own codebase nothing breaks, but it's relatively small.
>
> On the related question, I like the idea of nulling out the current value
>> when a property is bound.
>>
>
> I can pick up from where the older PR stopped. It's a simple change.
>
> On Wed, Oct 6, 2021 at 3:15 AM Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
>
>> Given that the intention of InvalidationListener was to be a light-weight
>> way to listen to properties without causing a binding chain to be
>> revalidated, it does seem reasonable to me that the listener is only fired
>> on the valid --> invalid transition, which is the specified behavior, even
>> if the implementation doesn't currently do that in all cases.
>>
>> The two related questions then are:
>>
>> 1. Should adding an invalidation listener to property do an immediate
>> get(), which will ensure that the property is then valid? This will force
>> an eager evaluation of the property and "arm" the property to fire an
>> invalidation even the next time it is invalidated.
>>
>> 2. Should adding an invalidation listener to a currently invalid property
>> cause the listener to be called (either immediately or the next time the
>> object is invalidated)?
>>
>> I think the ideal answer to both questions is "no", although I share
>> John's concern that changing this behavior for InvalidationListeners could
>> break applications. So the question is: how likely do we think that
>> changing this behavior will break existing applications?
>>
>> I think it's something we can and should consider changing. Unless there
>> are serious concerns, I would support changing this behavior as part of
>> avoiding eager evaluation when using invalidation listeners. It would need
>> to be well tested (of course), and would need a CSR describing the
>> compatibility risk, and should probably get a release note.
>>
>> Any concerns in doing this?
>>
>> On the related question, I like the idea of nulling out the current value
>> when a property is bound.
>>
>> -- Kevin
>>
>>
>> On 9/11/2021 9:41 AM, Nir Lisker wrote:
>>
>> I think that we need your input on this to move it forward.
>>
>> On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com> wrote:
>>
>>> so the value field should perhaps be nulled out when bound.
>>>
>>>
>>> There was a PR for something like that in the old repo:
>>> https://github.com/javafxports/openjdk-jfx/pull/110
>>> <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
>>>
>>> On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl> wrote:
>>>
>>>>
>>>>
>>>> On 02/09/2021 11:57, Nir Lisker wrote:
>>>>>     So in order
>>>>>     to make sure that a new interested invalidation listener does not
>>>> miss
>>>>>     the fact that a property was *already* invalid, the easiest
>>>> solution
>>>>>     might have been to revalidate it upon registration of a new
>>>> listener
>>>>>
>>>>>
>>>>> But why does an invalidation listener need to know the past state of
>>>> the
>>>>> property? It is only interested in the valid -> invalid transition. If
>>>>> the property was invalid then the listener (in theory) shouldn't
>>>> receive
>>>>> any events anyway on subsequent invalidations. (I understand that you
>>>>> don't justify this, I'm posing it as a general question.)
>>>>
>>>> Strictly speaking, no, if users are using InvalidationListener correctly
>>>> then this is definitely correct behavior. I'm not really advocating a
>>>> change, and I'd even prefer that it be brought in line with the
>>>> documentation.
>>>>
>>>> I think however that many users are not using it correctly and expect an
>>>> invalidation event always the next time the value changes (and their
>>>> listener will read that value, validating it again), making it act like
>>>> a light-weight ChangeListener. I know that I probably have written code
>>>> that made that assumption, and would in the past not even think twice
>>>> about replacing a change with an invalidation listener or vice versa if
>>>> that happened to be a better fit. Which is sort of what happened as well
>>>> in the bidirectional binding PR, and the issue slipped past the author
>>>> and two reviewers.
>>>>
>>>>> I suggest that we split the problem into 2: one is the case where the
>>>>> property was valid when the listener was attached, and the other is
>>>> when
>>>>> it was invalid.
>>>>> * A valid starting state. In this case attaching a listener shouldn't
>>>>> need to do anything. A subsequent invalidation event will be sent
>>>>> regardless. Currently, it is calling get() redundantly.
>>>>
>>>> True, the call to get is redundant in this case. Ugly too, calling get
>>>> and discarding its result, while the intention is to force the property
>>>> to become valid.
>>>>
>>>>> * An invalid starting state. In this case the documentation says that
>>>>> nothing needs to happen, but get() is called anyway. Here, the
>>>>> difference is that a subsequent invalidation event is sent in one case
>>>>> and not in the other. The only way to advance here is to make a design
>>>>> decision on what should happen, at least that's how I see it.
>>>>
>>>> The docs are even more specific I think, they say no more events will be
>>>> generated until it becomes valid -- it doesn't leave any option open
>>>> that it could generate events if it wanted to.
>>>>
>>>>> As to the implementation of a possible solution, suppose we add the
>>>>> isValid method. Upon attaching an invalidation listener, if the
>>>> property
>>>>> is valid, we can skip the get() call. That solves the valid starting
>>>>> state issue. The question is what to do if the property is not valid.
>>>>>
>>>>> I also noticed an odd design choice in the implementation of
>>>> properties:
>>>>> the value field does not update if the property is bound, instead, the
>>>>> result of the binding is returned and the value field holds an outdated
>>>>> value (until the property is unbound).
>>>>
>>>> Yeah, that might not be a wise decision as that can lead to memory being
>>>> referenced that users might expect to be freed. I didn't see anywhere
>>>> defined what will happen to the value of the property when it is unbound
>>>> again. The current implementation will keep its last value (during the
>>>> unbind it will take the last value and assign it to its own value
>>>> field), so the value field should perhaps be nulled out when bound.
>>>>
>>>> --John
>>>>
>>>
>>
>

From mhanl at openjdk.java.net  Wed Oct  6 07:48:20 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Wed, 6 Oct 2021 07:48:20 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS
Message-ID: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>

This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
Also a ClassCastException is thrown (The converter expects a String, but gets a Color).

Note: There is another similar bug but I can't reproduce this (Tried on 18-ea+3).
https://bugs.openjdk.java.net/browse/JDK-8268657

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

Commit messages:
 - 8274699: Blend mode won't be detected and converted as color anymore

Changes: https://git.openjdk.java.net/jfx/pull/640/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=640&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274699
  Stats: 21 lines in 2 files changed: 9 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/640.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/640/head:pull/640

PR: https://git.openjdk.java.net/jfx/pull/640

From rlichten at openjdk.java.net  Wed Oct  6 12:26:09 2021
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 6 Oct 2021 12:26:09 GMT
Subject: RFR: 8274137: TableView scrollbar/header misaligned when
 reloading data [v3]
In-Reply-To: <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
References: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
 <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
Message-ID: <7IkBf3H5avnF6TdUdLdesjPQi8bP_xpHRbZ_qg9BHNc=.df7d5260-59f7-483e-829c-ac6566724ceb@github.com>

On Mon, 27 Sep 2021 05:27:25 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene.
>> Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time.
>> 
>> A test agains VirtualFlow has been added that will fail before the change and pass afterwards.
>
> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274137: TableView scrollbar/header misaligned when reloading data
>   
>   Remove @Override annotations unrelated to fix.

Ist there anything left for me to do? IIRC someone must now /sponsor this change and then I can /integrate it, right?

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

PR: https://git.openjdk.java.net/jfx/pull/629

From pbansal at openjdk.java.net  Wed Oct  6 14:34:11 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Wed, 6 Oct 2021 14:34:11 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v3]
In-Reply-To: <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
Message-ID: <7g1eOkl9TesInNEI8-46c5Ju--geCSg2skAh76EOLfw=.34f371c4-c2ad-435f-ab9a-78ff0a009d98@github.com>

On Wed, 22 Sep 2021 16:39:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Found the problem thru this path:
>> 
>> **WindowStage.java**
>> 
>>     final void handleFocusDisabled() {
>>         if (activeWindows.isEmpty()) {
>>             return;
>>         }
>>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>>         window.setIconified(false);
>>         window.requestToFront();
>>         window.requestFocus();
>>     }
>> 
>> 
>> **glass_window.cpp**
>> 
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>    ...
>> 
>>     if (jwindow) {
>>         if (!event->in || isEnabled()) {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         } else {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         }
>>     }
>> }
>> 
>> 
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
>> 
>> The docs states:
>> 
>>     /**
>>      * Enables or disables the window.
>>      *
>>      * A disabled window is unfocusable by definition.
>>      * Also, key or mouse events aren't generated for disabled windows.
>>      *
>>      * When a user tries to activate a disabled window, or the window gets
>>      * accidentally brought to the top of the stacking order, the window
>>      * generates the FOCUS_DISABLED window event. A Glass client should react
>>      * to this event and bring the currently active modal blocker of the
>>      * disabled window to top by calling blocker's minimize(false), toFront(),
>>      * and requestFocus() methods. It may also 'blink' the blocker window to
>>      * further attract user's attention.
>>      *
>>      .....
>> 
>> 
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
>> 
>> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break if reach self

I tested this using the manual test and looks ok to me. I ran the system tests and it is not introducing any regression.

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

Marked as reviewed by pbansal (Committer).

PR: https://git.openjdk.java.net/jfx/pull/598

From mhanl at openjdk.java.net  Wed Oct  6 15:18:09 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Wed, 6 Oct 2021 15:18:09 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <A_OdJvtJRPMYlnNvApUQjivBSj2L_-i5eCLaROwlPFk=.53a6aba4-87b1-4c28-98f9-12b686436267@github.com>

On Tue, 5 Oct 2021 13:18:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

Interesting, I just saw that it worked before because of the TableCellBehavior (edit method). Does this mean this can be removed from the behaviour in future?

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

PR: https://git.openjdk.java.net/jfx/pull/638

From fastegal at openjdk.java.net  Wed Oct  6 15:37:11 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 6 Oct 2021 15:37:11 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <A_OdJvtJRPMYlnNvApUQjivBSj2L_-i5eCLaROwlPFk=.53a6aba4-87b1-4c28-98f9-12b686436267@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <A_OdJvtJRPMYlnNvApUQjivBSj2L_-i5eCLaROwlPFk=.53a6aba4-87b1-4c28-98f9-12b686436267@github.com>
Message-ID: <SeRCrrarSJM-B83071BPRmJYcTx5YV5Y_YBd-XXt8h8=.76482df9-b652-4297-9018-fb3d0215f08f@github.com>

On Wed, 6 Oct 2021 15:15:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> 
> 
> Interesting, I just saw that it worked before because of the TableCellBehavior (edit method). Does this mean this can be removed from the behaviour in future?

hmm .. the behavior talks directly to the control (not the cell) by invoking control.edit(...) - which might be a problem (or not, didn't look closely yet - left to later when dealing with with big big edit issue ;)

The issue here is cell.startEdit which must call the control.edit(...) to switch the control into editing, independent on other parties.

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

PR: https://git.openjdk.java.net/jfx/pull/638

From michaelstrau2 at gmail.com  Wed Oct  6 17:02:06 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 6 Oct 2021 19:02:06 +0200
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
Message-ID: <CAJEpuXTJZrhgFp1V_CpGeGGH+jPhTasZ=WP5me7j9zUuoQALiQ@mail.gmail.com>

The documentation of `Observable` states that "an implementation [...]
may support lazy evaluation" and that "implementations [...] should
strive to generate as few events as possible".
This seems to me like it would be within spec to fire an invalidation
event for every single change. It would also be within spec to fire
redundant invalidation events only in certain scenarios (like adding a
listener).

The problem could also be approached from a different angle: what does
it mean for a property to be "valid"?
As implemented, the "valid" state is an opaque and unknowable
implementation detail. We could re-define "valid" to mean: valid from
the perspective of an InvalidationListener.
A newly-added InvalidationListener wouldn't know that the property is
invalid (and has no way of knowing), and can therefore reasonably
assume that, from its perspective, the property is valid. It would
receive an invalidation event when the property value is changed.
>From the perspective of pre-existing listeners, however, the property
could well have been invalid all the time, so they won't receive an
invalidation event.

On Wed, Oct 6, 2021 at 2:16 AM Kevin Rushforth
<kevin.rushforth at oracle.com> wrote:
>
> Given that the intention of InvalidationListener was to be a
> light-weight way to listen to properties without causing a binding chain
> to be revalidated, it does seem reasonable to me that the listener is
> only fired on the valid --> invalid transition, which is the specified
> behavior, even if the implementation doesn't currently do that in all cases.
>
> The two related questions then are:
>
> 1. Should adding an invalidation listener to property do an immediate
> get(), which will ensure that the property is then valid? This will
> force an eager evaluation of the property and "arm" the property to fire
> an invalidation even the next time it is invalidated.
>
> 2. Should adding an invalidation listener to a currently invalid
> property cause the listener to be called (either immediately or the next
> time the object is invalidated)?
>
> I think the ideal answer to both questions is "no", although I share
> John's concern that changing this behavior for InvalidationListeners
> could break applications. So the question is: how likely do we think
> that changing this behavior will break existing applications?
>
> I think it's something we can and should consider changing. Unless there
> are serious concerns, I would support changing this behavior as part of
> avoiding eager evaluation when using invalidation listeners. It would
> need to be well tested (of course), and would need a CSR describing the
> compatibility risk, and should probably get a release note.
>
> Any concerns in doing this?
>
> On the related question, I like the idea of nulling out the current
> value when a property is bound.
>
> -- Kevin
>
>
> On 9/11/2021 9:41 AM, Nir Lisker wrote:
> > I think that we need your input on this to move it forward.
> >
> > On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com
> > <mailto:nlisker at gmail.com>> wrote:
> >
> >         so the value field should perhaps be nulled out when bound.
> >
> >
> >     There was a PR for something like that in the old repo:
> >     https://github.com/javafxports/openjdk-jfx/pull/110
> >     <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
> >
> >     On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl
> >     <mailto:hjohn at xs4all.nl>> wrote:
> >
> >
> >
> >         On 02/09/2021 11:57, Nir Lisker wrote:
> >         >     So in order
> >         >     to make sure that a new interested invalidation listener
> >         does not miss
> >         >     the fact that a property was *already* invalid, the
> >         easiest solution
> >         >     might have been to revalidate it upon registration of a
> >         new listener
> >         >
> >         >
> >         > But why does an invalidation listener need to know the past
> >         state of the
> >         > property? It is only interested in the valid -> invalid
> >         transition. If
> >         > the property was invalid then the listener (in theory)
> >         shouldn't receive
> >         > any events anyway on subsequent invalidations. (I understand
> >         that you
> >         > don't justify this, I'm posing it as a general question.)
> >
> >         Strictly speaking, no, if users are using InvalidationListener
> >         correctly
> >         then this is definitely correct behavior. I'm not really
> >         advocating a
> >         change, and I'd even prefer that it be brought in line with the
> >         documentation.
> >
> >         I think however that many users are not using it correctly and
> >         expect an
> >         invalidation event always the next time the value changes (and
> >         their
> >         listener will read that value, validating it again), making it
> >         act like
> >         a light-weight ChangeListener. I know that I probably have
> >         written code
> >         that made that assumption, and would in the past not even
> >         think twice
> >         about replacing a change with an invalidation listener or vice
> >         versa if
> >         that happened to be a better fit. Which is sort of what
> >         happened as well
> >         in the bidirectional binding PR, and the issue slipped past
> >         the author
> >         and two reviewers.
> >
> >         > I suggest that we split the problem into 2: one is the case
> >         where the
> >         > property was valid when the listener was attached, and the
> >         other is when
> >         > it was invalid.
> >         > * A valid starting state. In this case attaching a listener
> >         shouldn't
> >         > need to do anything. A subsequent invalidation event will be
> >         sent
> >         > regardless. Currently, it is calling get() redundantly.
> >
> >         True, the call to get is redundant in this case. Ugly too,
> >         calling get
> >         and discarding its result, while the intention is to force the
> >         property
> >         to become valid.
> >
> >         > * An invalid starting state. In this case the documentation
> >         says that
> >         > nothing needs to happen, but get() is called anyway. Here, the
> >         > difference is that a subsequent invalidation event is sent
> >         in one case
> >         > and not in the other. The only way to advance here is to
> >         make a design
> >         > decision on what should happen, at least that's how I see it.
> >
> >         The docs are even more specific I think, they say no more
> >         events will be
> >         generated until it becomes valid -- it doesn't leave any
> >         option open
> >         that it could generate events if it wanted to.
> >
> >         > As to the implementation of a possible solution, suppose we
> >         add the
> >         > isValid method. Upon attaching an invalidation listener, if
> >         the property
> >         > is valid, we can skip the get() call. That solves the valid
> >         starting
> >         > state issue. The question is what to do if the property is
> >         not valid.
> >         >
> >         > I also noticed an odd design choice in the implementation of
> >         properties:
> >         > the value field does not update if the property is bound,
> >         instead, the
> >         > result of the binding is returned and the value field holds
> >         an outdated
> >         > value (until the property is unbound).
> >
> >         Yeah, that might not be a wise decision as that can lead to
> >         memory being
> >         referenced that users might expect to be freed. I didn't see
> >         anywhere
> >         defined what will happen to the value of the property when it
> >         is unbound
> >         again. The current implementation will keep its last value
> >         (during the
> >         unbind it will take the last value and assign it to its own value
> >         field), so the value field should perhaps be nulled out when
> >         bound.
> >
> >         --John
> >
>

From tsayao at openjdk.java.net  Wed Oct  6 18:40:07 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Wed, 6 Oct 2021 18:40:07 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation
In-Reply-To: <_rx9AalZNfMzhWtdk8n7ODjN9356jfjuJSPS9hKcPWo=.b58f0693-5921-48d9-8006-8a469929b41e@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <3bjat4WLePrqj9ZLIXfU9QQFNY8Xji2h5OMyTuieVcg=.d30af751-a0b7-4023-af91-41456a5df715@github.com>
 <_rx9AalZNfMzhWtdk8n7ODjN9356jfjuJSPS9hKcPWo=.b58f0693-5921-48d9-8006-8a469929b41e@github.com>
Message-ID: <4hTH6x1uIxIbZPuXIv092BIT-RXkvoiWxxXlBK5Gfns=.4e075d49-8b30-49d3-b07a-9f9945d96f66@github.com>

On Mon, 16 Aug 2021 06:23:01 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Weird, It works consistently for me on 20.04. Just tested again to be sure.
>
>> Weird, It works consistently for me on 20.04. Just tested again to be sure.
> 
> I am running a 20.04 VM. The test fails for me 60-70% of the time. I will request someone in team to try this once.

@pankaj-bansal Can you try the test attached to the JBS on macos and windows? Thanks.

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

PR: https://git.openjdk.java.net/jfx/pull/598

From jvos at openjdk.java.net  Wed Oct  6 19:45:11 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 6 Oct 2021 19:45:11 GMT
Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]
In-Reply-To: <7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25@github.com>
References: <wqczQSMrWbX5jGjbbINLlChHN4qGcbowKhS851EGIyw=.bfb72ac4-78ea-4f08-80fd-67521e15b139@github.com>
 <af16EMYjHH_Z-if3BW21v2Y0qyv6Me8i_R_aiLaujIk=.cf13701f-e3d8-42a2-864f-64326d2e1057@github.com>
 <s-ciGHyebbD-kYO-KyE9eimYF-iyxnbFydYbfehU-tY=.36968fea-4f03-4958-a2fc-6cbf76f0c366@github.com>
 <GEcMPiBwM5iYTQoa4LpN5MLCa4vwil7JjVUIMGv0yAE=.13402ef3-c387-4e9d-a6e2-64a492246e56@github.com>
 <7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25@github.com>
Message-ID: <ic-GA4oYCr2VoKoCnfSr-7nfeNfovALVHWtJQXk4mYE=.7027a77e-03f7-4d49-9f8c-0bb09d76bc60@github.com>

On Tue, 25 May 2021 18:29:45 GMT, Martin Fox <github.com+12087024+beldenfox at openjdk.org> wrote:

>> @beldenfox I did not say that the swing version is the way to go and in the end its @kevinrushforth call what route should be taken - I just wanted to show what my initial change would have been without saying it is better than what you are proposing which sounds like is more complete than what swing provides today.
>
> @tomsontom I've added the Swing-style code as WIP PR #519. There are comments in the PR that probably should be in the code but I wanted to reduce the code diffs.
> 
> PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US layouts. That's not a big issue for accelerator processing since accelerators involving punctuation should use KeyCharacterCombinations which work even if the underlying key codes are wrong.  (I can't seem to find documentation that tells developers how to choose between KeyCodeCombinations and KeyCharacterCombinations. Am I missing something?)
> 
> There are isolated instances where PR #519 assigns a letter code to a punctuation key. For example, on the French keyboard it assigns KeyCode.M to the comma/question mark key which is where the M key is on the US layout. This means an app that uses both M and one of those punctuation characters as accelerators might see both fire. This might be a non-issue, the same problem afflicts the current code and I didn't run across any bugs on that.

@beldenfox Can you somehow add the test you talked about in a previous comment? It always helps to have a test that fails before and succeeds after.
Let me know if you need help with this?

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

PR: https://git.openjdk.java.net/jfx/pull/425

From github.com+12087024+beldenfox at openjdk.java.net  Wed Oct  6 20:21:17 2021
From: github.com+12087024+beldenfox at openjdk.java.net (Martin Fox)
Date: Wed, 6 Oct 2021 20:21:17 GMT
Subject: RFR: 8150709: Mac OSX and German Keyboard Layout (Y/Z) [v4]
In-Reply-To: <ic-GA4oYCr2VoKoCnfSr-7nfeNfovALVHWtJQXk4mYE=.7027a77e-03f7-4d49-9f8c-0bb09d76bc60@github.com>
References: <wqczQSMrWbX5jGjbbINLlChHN4qGcbowKhS851EGIyw=.bfb72ac4-78ea-4f08-80fd-67521e15b139@github.com>
 <af16EMYjHH_Z-if3BW21v2Y0qyv6Me8i_R_aiLaujIk=.cf13701f-e3d8-42a2-864f-64326d2e1057@github.com>
 <s-ciGHyebbD-kYO-KyE9eimYF-iyxnbFydYbfehU-tY=.36968fea-4f03-4958-a2fc-6cbf76f0c366@github.com>
 <GEcMPiBwM5iYTQoa4LpN5MLCa4vwil7JjVUIMGv0yAE=.13402ef3-c387-4e9d-a6e2-64a492246e56@github.com>
 <7psvBBkKDCQo8VUJPCE3CmreXLyr_d97fy0v-j81TnM=.d1ba2101-11d7-4e46-8175-97e657e2eb25@github.com>
 <ic-GA4oYCr2VoKoCnfSr-7nfeNfovALVHWtJQXk4mYE=.7027a77e-03f7-4d49-9f8c-0bb09d76bc60@github.com>
Message-ID: <k2HT89DH4q7Iq0VsNW_Ygc2LnMaCsWBWmgERmOT6uco=.f8ec36fe-53ea-4212-8a29-6fcf3ee47192@github.com>

On Wed, 6 Oct 2021 19:42:41 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> @tomsontom I've added the Swing-style code as WIP PR #519. There are comments in the PR that probably should be in the code but I wanted to reduce the code diffs.
>> 
>> PR #519 (and Swing) tend to get codes for punctuation keys wrong on non-US layouts. That's not a big issue for accelerator processing since accelerators involving punctuation should use KeyCharacterCombinations which work even if the underlying key codes are wrong.  (I can't seem to find documentation that tells developers how to choose between KeyCodeCombinations and KeyCharacterCombinations. Am I missing something?)
>> 
>> There are isolated instances where PR #519 assigns a letter code to a punctuation key. For example, on the French keyboard it assigns KeyCode.M to the comma/question mark key which is where the M key is on the US layout. This means an app that uses both M and one of those punctuation characters as accelerators might see both fire. This might be a non-issue, the same problem afflicts the current code and I didn't run across any bugs on that.
>
> @beldenfox Can you somehow add the test you talked about in a previous comment? It always helps to have a test that fails before and succeeds after.
> Let me know if you need help with this?

@johanvos I've attached my test app to this comment. The test I was referring to is invoked using the `A-Z Test` button down at the bottom. The test just sends KeyCodes A-Z using the Robot and verifies that the expected KeyCodes and characters come back.


[KeyboardTest.txt](https://github.com/openjdk/jfx/files/7296937/KeyboardTest.txt)

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

PR: https://git.openjdk.java.net/jfx/pull/425

From fastegal at openjdk.java.net  Thu Oct  7 09:33:10 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Thu, 7 Oct 2021 09:33:10 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <SeRCrrarSJM-B83071BPRmJYcTx5YV5Y_YBd-XXt8h8=.76482df9-b652-4297-9018-fb3d0215f08f@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <A_OdJvtJRPMYlnNvApUQjivBSj2L_-i5eCLaROwlPFk=.53a6aba4-87b1-4c28-98f9-12b686436267@github.com>
 <SeRCrrarSJM-B83071BPRmJYcTx5YV5Y_YBd-XXt8h8=.76482df9-b652-4297-9018-fb3d0215f08f@github.com>
Message-ID: <0Bmv8O1Cj9lw0f6h8rxiIp223EV_bD81Xzdpi_CilN8=.a82ed19b-2170-4981-83fc-390a0ffa93ee@github.com>

On Wed, 6 Oct 2021 15:34:14 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> 
> > Interesting, I just saw that it worked before because of the TableCellBehavior (edit method). Does this mean this can be removed from the behaviour in future?
> 
> hmm .. the behavior talks directly to the control (not the cell) by invoking control.edit(...) - which might be a problem (or not, didn't look closely yet - left to later when dealing with with big big edit issue ;)

an aside I forgot to mention yesterday: this interference from behavior (triggered by mouseEvents) is one of the major stumbling-blocks in solving the ominous commit-on-focusLost issue - by _cancelling_ an edit.

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

PR: https://git.openjdk.java.net/jfx/pull/638

From mhanl at openjdk.java.net  Thu Oct  7 10:38:07 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 7 Oct 2021 10:38:07 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <SeRCrrarSJM-B83071BPRmJYcTx5YV5Y_YBd-XXt8h8=.76482df9-b652-4297-9018-fb3d0215f08f@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <A_OdJvtJRPMYlnNvApUQjivBSj2L_-i5eCLaROwlPFk=.53a6aba4-87b1-4c28-98f9-12b686436267@github.com>
 <SeRCrrarSJM-B83071BPRmJYcTx5YV5Y_YBd-XXt8h8=.76482df9-b652-4297-9018-fb3d0215f08f@github.com>
Message-ID: <qgBFtJlEcjnQmfFiW_ro2pErlUYm7cyVKRaxq4cICo0=.3ecafa5d-8e1f-4ca8-a5d2-fd66d57e65a2@github.com>

On Wed, 6 Oct 2021 15:34:14 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> > Interesting, I just saw that it worked before because of the TableCellBehavior (edit method). Does this mean this can be removed from the behaviour in future?
> 
> hmm .. the behavior talks directly to the control (not the cell) by invoking control.edit(...) - which might be a problem (or not, didn't look closely yet - left to later when dealing with with big big edit issue ;)
> 
> The issue here is cell.startEdit which must call the control.edit(...) to switch the control into editing, independent on other parties.

Yeah right, just want to share my findings though. :)
The whole behaviour stuff is weird anyway, also given that there is still no way do change the behaviour without accessing the api.

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

PR: https://git.openjdk.java.net/jfx/pull/638

From mhanl at openjdk.java.net  Thu Oct  7 10:38:08 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 7 Oct 2021 10:38:08 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <gFtOz8Ys0qDo0AAa6GdR6Fu2CkxKK9x0MnMrl8a3SuI=.bc0e2e16-8ab2-4d7e-b620-97aa984a826a@github.com>

On Tue, 5 Oct 2021 13:18:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

And by the way, you know why there is a requestFocus() in List/TreeCell, but not in the other two cells? :)

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

PR: https://git.openjdk.java.net/jfx/pull/638

From cstein at openjdk.java.net  Thu Oct  7 16:58:09 2021
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 7 Oct 2021 16:58:09 GMT
Subject: RFR: 8267472: JavaFX modules to include version information [v3]
In-Reply-To: <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com>
References: <x3kwqCidIJga6nK1A7ztoVaP7r7Ln-xss5QrO_zxPMQ=.daa316a2-30b8-469d-8120-b4d6c9143c45@github.com>
 <8NAGYVneGFD4LgfQ6J2otsCZPpPPaREyHMdBK9AwLD8=.a1d59afb-a6f6-49e4-b16c-e1487b3cd91a@github.com>
Message-ID: <DL9m3sTWW9hPgtHF1R5upU1e_dHFNn9wvfD06gsoNoc=.ea4b46d3-5363-40f8-98aa-c69a187a18fd@github.com>

On Mon, 23 Aug 2021 18:18:51 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8267472
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add module version to `graphics` and `web` project's compiler args

I ran a local test using Java `17` and OpenJFX `18-ea+3` and that yielded:

`.bach\workspace\image\bin\java --list-modules`

com.github.sormuras.bach.javafx at 1
java.base at 17
java.datatransfer at 17
java.desktop at 17
java.prefs at 17
java.xml at 17
javafx.base at 18-ea
javafx.controls at 18-ea
javafx.graphics at 18-ea
jdk.unsupported at 17


The version (`18`) and pre-release token (`ea`) are present, the build token `3` is not.

Shall I open a new issue in order to investigate why the build token is not included - and fix it?

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

PR: https://git.openjdk.java.net/jfx/pull/608

From nlisker at openjdk.java.net  Thu Oct  7 19:06:10 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 7 Oct 2021 19:06:10 GMT
Subject: Integrated: 8272870: Add convenience factory methods for border and
 background
In-Reply-To: <knuGZVSEYvUqgPhBAzgWcK4JM5yLOkbcZNihKRjL--4=.5d2471a8-f9a0-45a3-a38b-4431bd469285@github.com>
References: <knuGZVSEYvUqgPhBAzgWcK4JM5yLOkbcZNihKRjL--4=.5d2471a8-f9a0-45a3-a38b-4431bd469285@github.com>
Message-ID: <q31xc8YZFR3QpcfIkVO-6dYar83jBe8_ALDv3IlWFRg=.4e36e92a-1ba1-44a5-a2aa-837ed0fd8c86@github.com>

On Tue, 24 Aug 2021 16:29:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Added convenience factory factory methods for Background and Border.

This pull request has now been integrated.

Changeset: bb73d43b
Author:    Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/bb73d43b57c4da9713fb0213e156d61aab873b9a
Stats:     59 lines in 4 files changed: 59 ins; 0 del; 0 mod

8272870: Add convenience factory methods for border and background

Reviewed-by: kcr, arapte

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

PR: https://git.openjdk.java.net/jfx/pull/610

From hjohn at xs4all.nl  Thu Oct  7 23:55:23 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Fri, 8 Oct 2021 01:55:23 +0200
Subject: Proof of concept for fluent bindings for ObservableValue
In-Reply-To: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
References: <19abcac8-39fd-d82b-e450-171d1b7fc590@xs4all.nl>
Message-ID: <7a8deca6-79cb-d1bd-7332-7025705ac5b5@xs4all.nl>

Nir,

I've created a new branch which contains all the changes which we've 
discussed so far.  It contains JUnit 4 tests (in backported form), and a 
reduced API.

However, the changes made in the sandbox did not fully compile due to 
package restrictions, and I had to make a bit more API public.

The issue is that ObervableValue and ObjectBinding are in two different 
packages.  LazyObjectBinding must subclass ObjectBinding and requires 
two new methods (isObserved and allowInvalidation). ObservableValue uses 
classes like MappedBinding which subclass LazyObjectBinding.

Making the **Binding classes package private means ObservableValue can't 
access them. Moving the binding classes to ObservableValue's package 
means that LazyObjectBinding cannot access the isObserved and 
allowInvalidation methods of ObjectBinding.

So, we have two choices (that I can see):

1) Make LazyObjectBinding and subclasses public so they can be accessed 
from ObservableValue's package. LazyObjectBinding still must be in same 
package as ObjectBinding since the isObserved and allowInvalidation 
methods are package private.

2) Make isObserved and allowInvalidation *protected* methods of 
ObjectBinding so that LazyObjectBinding can access them from 
ObservableValue's package (also move all the other new binding classes 
there).

I went for the second option in my implementation as this exposes the 
least additional API.  I also think that the additions to ObjectBinding 
are relatively harmless, and in the case of isObserved might actually be 
useful for debugging.

If we ever want to make LazyObjectBinding and its subclasses public, 
we'd have to move them to the binding package as they make more sense 
there, but as long as they're package private they can safely live in 
the same package as ObservableValue.

Please see here for a draft version. If you could do a quick check and 
you're agreed with the route I took to resolve the package access 
restrictions, I can submit this as a PR:

https://github.com/hjohn/jfx/tree/feature/fluent-bindings

--John

On 24/03/2021 22:49, John Hendrikx wrote:
> I just wanted to draw some attention to a recent proof of concept I made
> in this pull request: https://github.com/openjdk/jfx/pull/434
>
> It is based on the work I did in
> https://github.com/hjohn/hs.jfx.eventstream which is in part based on
> work done in ReactFX by Tomas Mikula. The PR itself however shares no
> code with ReactFX and is
> completely written by me.
>
> If there is interest, I'm willing to invest more time in smoothing out
> the API and documentation, investigating further how this would interact
> with the primitive types and adding unit test coverage (I have extensive
> tests, but thesea are written in JUnit 5, so they would require
> conversion or JavaFX could move to support JUnit 5).
>
> What follows below is the text of the PR for easy reading. Feedback is
> appreciated.
>
> ================
>
> This is a proof of concept of how fluent bindings could be introduced to
> JavaFX. The main benefit of fluent bindings are ease of use, type safety
> and less surprises. Features:
>
> Flexible Mappings
> Map the contents of a property any way you like with map, or map nested
> properties with flatMap.
>
> Lazy
> The bindings created are lazy, which means they are always invalid when
> not themselves observed. This allows for easier garbage collection (once
> the last observer is removed, a chain of bindings will stop observing
> their parents) and less listener management when dealing with nested
> properties. Furthermore, this allows inclusion of such bindings in
> classes such as Node without listeners being created when the binding
> itself is not used (this would allow for the inclusion of a
> treeShowingProperty in Node without creating excessive listeners, see
> this fix I did in an earlier PR: #185)
>
> Null Safe
> The map and flatMap methods are skipped, similar to java.util.Optional
> when the value they would be mapping is null. This makes mapping nested
> properties with flatMap trivial as the null case does not need to be
> taken into account in a chain like this:
> node.sceneProperty().flatMap(Scene::windowProperty).flatMap(Window::showingProperty).
> Instead a default can be provided with orElse or orElseGet.
>
> Conditional Bindings
> Bindings can be made conditional using the conditionOn method. A
> conditional binding retains its last value when its condition is false.
> Conditional bindings donot observe their source when the condition is
> false, allowing developers to automatically stop listening to properties
> when a certain condition is met. A major use of this feature is to have
> UI components that need to keep models updated which may outlive the UI
> conditionally update the long lived model only when the UI is showing.
>
> Some examples:
>
> void mapProperty() {
>   // Standard JavaFX:
>   label.textProperty().bind(Bindings.createStringBinding(() ->
> text.getValueSafe().toUpperCase(), text));
>
>   // Fluent: much more compact, no need to handle null
>   label.textProperty().bind(text.map(String::toUpperCase));
> }
>
> void calculateCharactersLeft() {
>   // Standard JavaFX:
>
> label.textProperty().bind(text.length().negate().add(100).asString().concat("
> characters left"));
>
>   // Fluent: slightly more compact and more clear (no negate needed)
>   label.textProperty().bind(text.orElse("").map(v -> 100 - v.length() +
> " characters left"));
> }
>
> void mapNestedValue() {
>   // Standard JavaFX:
>   label.textProperty().bind(Bindings.createStringBinding(
>     () -> employee.get() == null ? ""
>         : employee.get().getCompany() == null ? ""
>         : employee.get().getCompany().getName(),
>     employee
>   ));
>
>   // Fluent: no need to handle nulls everywhere
>   label.textProperty().bind(
>     employee.map(Employee::getCompany)
>             .map(Company::getName)
>             .orElse("")
>   );
> }
>
> void mapNestedProperty() {
>   // Standard JavaFX:
>   label.textProperty().bind(
>     Bindings.when(Bindings.selectBoolean(label.sceneProperty(),
> "window", "showing"))
>       .then("Visible")
>       .otherwise("Not Visible")
>   );
>
>   // Fluent: type safe
>   label.textProperty().bind(label.sceneProperty()
>     .flatMap(Scene::windowProperty)
>     .flatMap(Window::showingProperty)
>     .orElse(false)
>     .map(showing -> showing ? "Visible" : "Not Visible")
>   );
> }
>
> void updateLongLivedModelWhileAvoidingMemoryLeaks() {
>   // Standard JavaFX: naive, memory leak; UI won't get garbage collected
>   listView.getSelectionModel().selectedItemProperty().addListener(
>     (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current)
>   );
>
>   // Standard JavaFX: no leak, but stops updating after a while
>   listView.getSelectionModel().selectedItemProperty().addListener(
>     new WeakChangeListener<>(
>       (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current)
>     )
>   );
>
>   // Standard JavaFX: fixed version
>   listenerReference = (obs, old, current) ->
> longLivedModel.lastSelectedProperty().set(current);
>
>   listView.getSelectionModel().selectedItemProperty().addListener(
>     new WeakChangeListener<>(listenerReference)
>   );
>
>   // Fluent: naive, memory leak... fluent won't solve this...
>   listView.getSelectionModel().selectedItemProperty()
>       .subscribe(longLivedModel.lastSelectedProperty()::set);
>
>   // Fluent: conditional update when control visible
>
>   // Create a property which is only true when the UI is visible:
>   ObservableValue<Boolean> showing = listView.sceneProperty()
>       .flatMap(Scene::windowProperty)
>       .flatMap(Window::showingProperty)
>       .orElse(false);
>
>   // Use showing property to automatically disconnect long lived model
>   // allowing garbage collection of the UI:
>   listView.getSelectionModel().selectedItemProperty()
>     .conditionOn(showing)
>     .subscribe(longLivedModel.lastSelectedProperty()::set);
>
>   // Note that the 'showing' property can be provided in multiple ways:
>   // - create manually (can be re-used for multiple bindings though)
>   // - create with a helper: Nodes.showing(Node node) ->
> ObservableValue<Boolean>
>   // - make it part of the Node class; as the fluent bindings only bind
> themselves
>   //   to their source when needed (lazy binding), this won't create
> overhead
>   //   for each node in the scene
> }
> Note that this is based on ideas in ReactFX and my own experiments in
> https://github.com/hjohn/hs.jfx.eventstream. I've come to the conclusion
> that this is much better directly integrated into JavaFX, and I'm hoping
> this proof of concept will be able to move such an effort forward.
>
> --John
>

From aghaisas at openjdk.java.net  Fri Oct  8 04:31:07 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 8 Oct 2021 04:31:07 GMT
Subject: RFR: 8274137: TableView scrollbar/header misaligned when
 reloading data [v3]
In-Reply-To: <7IkBf3H5avnF6TdUdLdesjPQi8bP_xpHRbZ_qg9BHNc=.df7d5260-59f7-483e-829c-ac6566724ceb@github.com>
References: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
 <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
 <7IkBf3H5avnF6TdUdLdesjPQi8bP_xpHRbZ_qg9BHNc=.df7d5260-59f7-483e-829c-ac6566724ceb@github.com>
Message-ID: <UZ_iPQDVdDZru5hz8ERiXPeLRoziSj6SCYOg_B4x8Dw=.a5bbd3e7-199d-44bc-aee9-89d865e5803c@github.com>

On Wed, 6 Oct 2021 12:22:54 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> Ist there anything left for me to do? IIRC someone must now /sponsor this change and then I can /integrate it, right?

This PR needs two review approvals; currently it has one.
We shall wait for @kevinrushforth to review and approve it. Once he does it, you can /integrate it and one of us will /sponsor it.

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

PR: https://git.openjdk.java.net/jfx/pull/629

From github.com+2310896+chilliger at openjdk.java.net  Mon Oct 11 14:48:14 2021
From: github.com+2310896+chilliger at openjdk.java.net (chilliger)
Date: Mon, 11 Oct 2021 14:48:14 GMT
Subject: RFR: 8217955: Problems with touch input and JavaFX 11
In-Reply-To: <bNO9wunLyNiGWcqLFVzSLrnsI5DMzW9pJg77_esrbPg=.b1b07612-6c4a-4c5a-9f86-e82bccbe4f1f@github.com>
References: <GY6BZE5415g2bQbv9RRbrMpch1Ol6ADJ4OYyQ7K3_KQ=.3fac0b8d-91f9-4d6a-8f94-164435e0ec55@github.com>
 <n-PICKMf1sM5YJINOis9TZUHjVYnaf1lcWtimWbAN3A=.c8044160-8a77-4cda-a984-e7991b3023c6@github.com>
 <bNO9wunLyNiGWcqLFVzSLrnsI5DMzW9pJg77_esrbPg=.b1b07612-6c4a-4c5a-9f86-e82bccbe4f1f@github.com>
Message-ID: <CHSZurGIeUyGCb499qVD5p_6TjcmbYcbgp0IW2Q2GU4=.6bb146ce-ed52-42c8-8936-877207a8fad6@github.com>

On Fri, 9 Apr 2021 15:49:45 GMT, Tor (torbuntu) <github.com+17347324+Torbuntu at openjdk.org> wrote:

>> This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation.
>
>> This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation.
> 
> What would be the protocol for requesting guidance on this? Since as I mentioned I am trying to [implement touch-event support ](https://github.com/torbuntu/jfx/tree/touch-support)so that JavaFX can be used out of the box on devices such as PinePhone and PineTab running aarch64 linux.

@Torbuntu What is the status? Are you still planning on implementing this?

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

PR: https://git.openjdk.java.net/jfx/pull/457

From github.com+17347324+torbuntu at openjdk.java.net  Mon Oct 11 17:27:13 2021
From: github.com+17347324+torbuntu at openjdk.java.net (Tor (torbuntu))
Date: Mon, 11 Oct 2021 17:27:13 GMT
Subject: RFR: 8217955: Problems with touch input and JavaFX 11
In-Reply-To: <bNO9wunLyNiGWcqLFVzSLrnsI5DMzW9pJg77_esrbPg=.b1b07612-6c4a-4c5a-9f86-e82bccbe4f1f@github.com>
References: <GY6BZE5415g2bQbv9RRbrMpch1Ol6ADJ4OYyQ7K3_KQ=.3fac0b8d-91f9-4d6a-8f94-164435e0ec55@github.com>
 <n-PICKMf1sM5YJINOis9TZUHjVYnaf1lcWtimWbAN3A=.c8044160-8a77-4cda-a984-e7991b3023c6@github.com>
 <bNO9wunLyNiGWcqLFVzSLrnsI5DMzW9pJg77_esrbPg=.b1b07612-6c4a-4c5a-9f86-e82bccbe4f1f@github.com>
Message-ID: <VYSjtEUPZoxDNsjm2TPeR43EFt4T20EcaCy78XvQWW0=.214f6ab0-9fd2-498f-b1f9-bc20133ba7b0@github.com>

On Fri, 9 Apr 2021 15:49:45 GMT, Tor (torbuntu) <github.com+17347324+Torbuntu at openjdk.org> wrote:

>> This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation.
>
>> This fixes a current issue, and while a solution that adds native touch-event support is highly encouraged, this fix will already improve the current situation.
> 
> What would be the protocol for requesting guidance on this? Since as I mentioned I am trying to [implement touch-event support ](https://github.com/torbuntu/jfx/tree/touch-support)so that JavaFX can be used out of the box on devices such as PinePhone and PineTab running aarch64 linux.

> @Torbuntu What is the status? Are you still planning on implementing this?

https://github.com/torbuntu/jfx/tree/touch-support <- This is the branch where I've been poking away at implementing touch support. I was trying to implement the correct gtk bindings but haven't looked at it in a few months when other things came up. Maybe some fresh eyes can help move this in the right direction? My last commit was some comments where I was working.

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

PR: https://git.openjdk.java.net/jfx/pull/457

From fastegal at openjdk.java.net  Mon Oct 11 17:40:13 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Mon, 11 Oct 2021 17:40:13 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <gFtOz8Ys0qDo0AAa6GdR6Fu2CkxKK9x0MnMrl8a3SuI=.bc0e2e16-8ab2-4d7e-b620-97aa984a826a@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <gFtOz8Ys0qDo0AAa6GdR6Fu2CkxKK9x0MnMrl8a3SuI=.bc0e2e16-8ab2-4d7e-b620-97aa984a826a@github.com>
Message-ID: <D8mGNGwiXwZKFmX-kGu_YxjTcVj3ZdSPZGLxIui2ETg=.c4ac8bdc-644b-4242-a83d-31093ce250ee@github.com>

On Thu, 7 Oct 2021 10:35:12 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> 
> 
> And by the way, you know why there is a requestFocus() in List/TreeCell, but not in the other two cells? :)

plain oversight? or the wrong thing to do, anyway? or having weird side-effects in tabular controls which were evaded by not requesting focus? We'll see the deeper we go in the cleanup quest :)

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

PR: https://git.openjdk.java.net/jfx/pull/638

From jhendrikx at openjdk.java.net  Tue Oct 12 13:38:50 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Tue, 12 Oct 2021 13:38:50 GMT
Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5]
In-Reply-To: <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
References: <rucQpoQckz65kU-gd1XWyNifMwzjSTOz197mwwEKTFQ=.189d92da-7491-42e0-8934-8a62904d6828@github.com>
 <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
Message-ID: <s-fPYxA302BpIeG792CZxJOz0FC_t4_K0xWy52elpn4=.f4ebc216-d087-4f7d-a90b-deb787f36b33@github.com>

On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work.  Also added a single JUnit 5 tests, and confirmed it works.
>> 
>> I've updated the Eclipse project file for the base module only.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd junit declaration in allprojects and set junit version to 4.13.2

The thread on the mailinglist to gauge interest seems to have been concluded.  We got 4 responses, all in favor.

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

PR: https://git.openjdk.java.net/jfx/pull/633

From kcr at openjdk.java.net  Tue Oct 12 14:51:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 12 Oct 2021 14:51:49 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v3]
In-Reply-To: <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
Message-ID: <xzdGNvysENIB9GF_DrVAmHERr5RR2Zoie4NB3VkEYmg=.440b681d-f25e-4832-a8e7-28f711ef84dd@github.com>

On Wed, 22 Sep 2021 16:39:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Found the problem thru this path:
>> 
>> **WindowStage.java**
>> 
>>     final void handleFocusDisabled() {
>>         if (activeWindows.isEmpty()) {
>>             return;
>>         }
>>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>>         window.setIconified(false);
>>         window.requestToFront();
>>         window.requestFocus();
>>     }
>> 
>> 
>> **glass_window.cpp**
>> 
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>    ...
>> 
>>     if (jwindow) {
>>         if (!event->in || isEnabled()) {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         } else {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         }
>>     }
>> }
>> 
>> 
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
>> 
>> The docs states:
>> 
>>     /**
>>      * Enables or disables the window.
>>      *
>>      * A disabled window is unfocusable by definition.
>>      * Also, key or mouse events aren't generated for disabled windows.
>>      *
>>      * When a user tries to activate a disabled window, or the window gets
>>      * accidentally brought to the top of the stacking order, the window
>>      * generates the FOCUS_DISABLED window event. A Glass client should react
>>      * to this event and bring the currently active modal blocker of the
>>      * disabled window to top by calling blocker's minimize(false), toFront(),
>>      * and requestFocus() methods. It may also 'blink' the blocker window to
>>      * further attract user's attention.
>>      *
>>      .....
>> 
>> 
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
>> 
>> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break if reach self

This fix reintroduced [JDK-8240640](https://bugs.openjdk.java.net/browse/JDK-8240640) on macOS. With the patch applied I get the following failure:


test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest > testWindowFocusByClosingAlerts FAILED
    java.lang.AssertionError: Timeout: Alerts not closed, wrong focus
        at org.junit.Assert.fail(Assert.java:91)
        at org.junit.Assert.assertTrue(Assert.java:43)
        at test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest.waitForLatch(WrongStageFocusWithApplicationModalityTest.java:82)
        at test.robot.javafx.stage.WrongStageFocusWithApplicationModalityTest.testWindowFocusByClosingAlerts(WrongStageFocusWithApplicationModalityTest.java:70)

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

PR: https://git.openjdk.java.net/jfx/pull/598

From kcr at openjdk.java.net  Tue Oct 12 15:16:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 12 Oct 2021 15:16:55 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v3]
In-Reply-To: <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
Message-ID: <gt4o3e8nAI7mSA2m_PM0NGtLh_v7a8IodsM11n_RHtw=.57ea9ba6-510a-40c7-a07b-cc757ef51538@github.com>

On Wed, 22 Sep 2021 16:39:15 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> Found the problem thru this path:
>> 
>> **WindowStage.java**
>> 
>>     final void handleFocusDisabled() {
>>         if (activeWindows.isEmpty()) {
>>             return;
>>         }
>>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>>         window.setIconified(false);
>>         window.requestToFront();
>>         window.requestFocus();
>>     }
>> 
>> 
>> **glass_window.cpp**
>> 
>> void WindowContextBase::process_focus(GdkEventFocus* event) {
>>    ...
>> 
>>     if (jwindow) {
>>         if (!event->in || isEnabled()) {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         } else {
>>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>>             CHECK_JNI_EXCEPTION(mainEnv)
>>         }
>>     }
>> }
>> 
>> 
>> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
>> 
>> The docs states:
>> 
>>     /**
>>      * Enables or disables the window.
>>      *
>>      * A disabled window is unfocusable by definition.
>>      * Also, key or mouse events aren't generated for disabled windows.
>>      *
>>      * When a user tries to activate a disabled window, or the window gets
>>      * accidentally brought to the top of the stacking order, the window
>>      * generates the FOCUS_DISABLED window event. A Glass client should react
>>      * to this event and bring the currently active modal blocker of the
>>      * disabled window to top by calling blocker's minimize(false), toFront(),
>>      * and requestFocus() methods. It may also 'blink' the blocker window to
>>      * further attract user's attention.
>>      *
>>      .....
>> 
>> 
>> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
>> 
>> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Break if reach self

The above test fails for me on Linux (Ubuntu 20.04 VM) as well. The manual test case attached to [JDK-8269429](https://bugs.openjdk.java.net/browse/JDK-8269429) also fails on Linux. I think you will need a solution that doesn't modify the logic in `WindowStage.java`.

modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 861:

> 859: 
> 860:         // walk backwards to find a blocker
> 861:         for (int i = activeWindows.size() - 1; i > 0; i--) {

I think you will need to revert this part of the change.

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

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/598

From pbansal at openjdk.java.net  Tue Oct 12 15:20:53 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 12 Oct 2021 15:20:53 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v3]
In-Reply-To: <gt4o3e8nAI7mSA2m_PM0NGtLh_v7a8IodsM11n_RHtw=.57ea9ba6-510a-40c7-a07b-cc757ef51538@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
 <gt4o3e8nAI7mSA2m_PM0NGtLh_v7a8IodsM11n_RHtw=.57ea9ba6-510a-40c7-a07b-cc757ef51538@github.com>
Message-ID: <FlIPbEanRcOEuI6QJUdYmsaJKDEmVW1Dc91PNcHBSro=.0abd67b2-dcb7-4a5b-a977-9c084f82de58@github.com>

On Tue, 12 Oct 2021 15:12:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Break if reach self
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 861:
> 
>> 859: 
>> 860:         // walk backwards to find a blocker
>> 861:         for (int i = activeWindows.size() - 1; i > 0; i--) {
> 
> I think you will need to revert this part of the change.

The test "WrongStageFocusWithApplicationModalityTest" passed for me on Ubuntu 20.04 VM. It failed first time, but when I re-ran it, it passed for me. I will run this change in Linux, Windows and Mac again today and report back.

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

PR: https://git.openjdk.java.net/jfx/pull/598

From tsayao at openjdk.java.net  Tue Oct 12 19:35:50 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Tue, 12 Oct 2021 19:35:50 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v3]
In-Reply-To: <FlIPbEanRcOEuI6QJUdYmsaJKDEmVW1Dc91PNcHBSro=.0abd67b2-dcb7-4a5b-a977-9c084f82de58@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
 <XRpVSvru3UMIDrI3UH3aPSUN94zd_yGnUN0LwUN1s8U=.547e34a5-a1d7-4a9d-ab8e-e101d804d07b@github.com>
 <gt4o3e8nAI7mSA2m_PM0NGtLh_v7a8IodsM11n_RHtw=.57ea9ba6-510a-40c7-a07b-cc757ef51538@github.com>
 <FlIPbEanRcOEuI6QJUdYmsaJKDEmVW1Dc91PNcHBSro=.0abd67b2-dcb7-4a5b-a977-9c084f82de58@github.com>
Message-ID: <Nz8sQR8MTbPW0TXxVaLObxrtWGVv08G_dVmfnWI38II=.00da1cd9-8c13-4cee-84da-a33d10c2145a@github.com>

On Tue, 12 Oct 2021 15:16:53 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java line 861:
>> 
>>> 859: 
>>> 860:         // walk backwards to find a blocker
>>> 861:         for (int i = activeWindows.size() - 1; i > 0; i--) {
>> 
>> I think you will need to revert this part of the change.
>
> The test "WrongStageFocusWithApplicationModalityTest" passed for me on Ubuntu 20.04 VM. It failed first time, but when I re-ran it, it passed for me. I will run this change in Linux, Windows and Mac again today and report back.

@pankaj-bansal Wait, because I will rework it since it fails on JDK-8269429 and  JDK-8240640.

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

PR: https://git.openjdk.java.net/jfx/pull/598

From kcr at openjdk.java.net  Wed Oct 13 12:41:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 13 Oct 2021 12:41:51 GMT
Subject: RFR: 8274137: TableView scrollbar/header misaligned when reloading
 data [v3]
In-Reply-To: <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
References: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
 <ADXtmRugBCczysrCf0i0EzGKa1v2wlwED8W5yYpcS1M=.4ab8a5a7-1936-4adf-aaa0-43dc87211f06@github.com>
Message-ID: <SKZm3b_7kmydXVBetITw_lt9qJgvJFGp_bNEcNG-JpA=.43e0e44e-76d0-484a-bf1e-810b2087baf3@github.com>

On Mon, 27 Sep 2021 05:27:25 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

>> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene.
>> Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time.
>> 
>> A test agains VirtualFlow has been added that will fail before the change and pass afterwards.
>
> Robert Lichtenberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274137: TableView scrollbar/header misaligned when reloading data
>   
>   Remove @Override annotations unrelated to fix.

Looks good.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/629

From rlichten at openjdk.java.net  Wed Oct 13 12:55:52 2021
From: rlichten at openjdk.java.net (Robert Lichtenberger)
Date: Wed, 13 Oct 2021 12:55:52 GMT
Subject: Integrated: 8274137: TableView scrollbar/header misaligned when
 reloading data
In-Reply-To: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
References: <b0Ny20-dE1v76wC_fegZpbsG5irZO8CENf1MLtbgCgg=.620a1f64-87da-4cc1-a522-931ddc66c975@github.com>
Message-ID: <NhcX0Ujxwdjh003F6iSnUNGKiECyhwZLNz5J3EOf74E=.d8cc14db-b067-4d20-ae16-e16248aa6d47@github.com>

On Thu, 23 Sep 2021 13:48:44 GMT, Robert Lichtenberger <rlichten at openjdk.org> wrote:

> This PR fixes JDK-8274137 by removing the optimization from updateHbar() that will no-op the method in case the VirtualFlow is invisible or currently has no scene.
> Since changes to the hBar's value can happen even if the VirtualFlow is not currently visible, the synchronisation between hBar and clipX must happen all the time.
> 
> A test agains VirtualFlow has been added that will fail before the change and pass afterwards.

This pull request has now been integrated.

Changeset: b591912c
Author:    Robert Lichtenberger <rlichten at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/b591912c749edef1e6c1b8509a8ea10e9fe9000f
Stats:     34 lines in 3 files changed: 34 ins; 0 del; 0 mod

8274137: TableView scrollbar/header misaligned when reloading data

Reviewed-by: kcr, aghaisas

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

PR: https://git.openjdk.java.net/jfx/pull/629

From mhanl at openjdk.java.net  Wed Oct 13 21:30:01 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Wed, 13 Oct 2021 21:30:01 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <aHJ2PvZhM8Z5HVnJeRBDbs0qVSabsGEmCBrsJ0oeGAw=.6066b293-7e96-4156-ab57-0959f47aec22@github.com>

On Tue, 5 Oct 2021 13:18:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

Looks good, just left one minor comment. :)

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 549:

> 547:         int editingRow = 1;
> 548:         cell.updateIndex(editingRow);
> 549:         TablePosition<?,?> editingCell = new TablePosition<>(table, editingRow, editingColumn);

Minor: There is a space missing in `<?,?>`

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

Marked as reviewed by mhanl (Author).

PR: https://git.openjdk.java.net/jfx/pull/638

From martin at martinfox.com  Wed Oct 13 23:10:58 2021
From: martin at martinfox.com (Martin Fox)
Date: Wed, 13 Oct 2021 16:10:58 -0700
Subject: Mac drag-and-drop questions
In-Reply-To: <4F21B1B2-6DC6-4541-B6FA-5D3B551D360F@martinfox.com>
References: <9DD23A68-A459-4379-AA96-173652C8D713@martinfox.com>
 <5f8fad69-dc92-6e93-c552-2796dd684e46@oracle.com>
 <4F21B1B2-6DC6-4541-B6FA-5D3B551D360F@martinfox.com>
Message-ID: <111155CC-2432-44DB-8D31-529DA52D322F@martinfox.com>

While researching JDK-8153032 I realized that part of the drag-and-drop API doesn?t make sense to me. From what I can determine there?s no reliable way of figuring out whether the user is holding down a modifier key or not while processing a drag event. On Windows DragEvent::getTransferMode() returns TransferMode.MOVE if the user is holding down Shift but also if the user isn?t holding down any key at all. There?s no way of distinguishing between these two cases. Linux has the same problem with TransferMode.COPY.

This seems like a major hole in the API. If the drop target wants to choose the transfer mode based on context it needs to know that the user isn?t trying to force a specific transfer mode. I don?t see how that?s possible with the current API.

> On Sep 30, 2021, at 3:55 PM, Martin Fox <martin at martinfox.com> wrote:
> 
> Kevin,
> 
> As a heads up there are actually two behavior changes to be reviewed. JavaFX is picking up some archaic behavior from the OS which thinks that the modifier key for LINK is Control. The Finder switched over to Option+Command a long time ago and I think JavaFX should follow suit.
> 
> As for finding older bugs I guess it?s just a matter of using the right Search box (my bad). Thanks.
> 
> Martin
> 
>> On Sep 30, 2021, at 3:19 PM, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> 
>> If changing the default behavior makes it consistent with native apps on macOS and with JavaFX apps on other platforms, then it seems like the right thing to do. We would want a CSR for the behavior change
>> 
>> As for your question about finding the bug using the old "RT-NNNN" bug ID, you can just paste that into the search box. It will redirect to the right bug:
>> 
>> https://bugs.openjdk.java.net/browse/RT-31449 --> https://bugs.openjdk.java.net/browse/JDK-8116268
>> 
>> -- Kevin
>> 
>> On 9/30/2021 3:03 PM, Martin Fox wrote:
>>> I was just looking at JDK-8237329 which is a drag-and-drop bug on the Mac; holding down the Command key alone is guaranteed to disable an internal dnd operation. I?m putting together a PR to fix this.
>>> 
>>> While going through the bug database looking for related bugs I ran across JDK-8153032 which notes that given a choice of TransferModes the Mac will default to COPY. This doesn?t match the JavaFX behavior on Windows or the user interface guidelines of any platform; normally the default operation is MOVE and the user has to press Option to force COPY. This bug makes it impossible for a control to get drag-and-drop right on the Mac. The code was last touched to address RT-31449 but it looks like the default mode was COPY even before that.
>>> 
>>> So my question is whether or not to fix this long-standing but incorrect behavior. I ask because If we?re going to fix the COPY bug I think it should be tested in conjunction with the fix for the modifier keys.
>>> 
>>> BTW, when I run across a reference to something like RT-31449 is there any way to look at the details of the original bug?
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8237329 <https://bugs.openjdk.java.net/browse/JDK-8237329>
>>> https://bugs.openjdk.java.net/browse/JDK-8153032
>>> https://bugs.openjdk.java.net/browse/JDK-8264172
>>> https://bugs.openjdk.java.net/browse/JDK-8227371 <https://bugs.openjdk.java.net/browse/JDK-8227371>
>>> 
>> 
> 


From prr at openjdk.java.net  Thu Oct 14 00:03:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 14 Oct 2021 00:03:59 GMT
Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly
Message-ID: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>

On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
Retina diminishes it rather than cures it.

The problem is a mix of a couple of things
1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
glyphs into multi-coloured glyphs that weren't meant to be ...

The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
by just specifying -Dprism.lcdtext=on

Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

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

Commit messages:
 - 8236689: macOS 10.15 Catalina: LCD text renders badly

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

PR: https://git.openjdk.java.net/jfx/pull/642

From kcr at openjdk.java.net  Thu Oct 14 12:38:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 12:38:08 GMT
Subject: RFR: 8275138: WebView: UserAgent string is empty for first request
Message-ID: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>

The failure was caused by a change that was done in connection with the WebKit 610.2 update, [JDK-8259635](https://bugs.openjdk.java.net/browse/JDK-8259635). The `FrameLoaderClient::userAgent` function was changed in WebKit itself to be a const method in WebKit 610.2. We override that method in `FrameLoaderClientJava` to return the user agent string, which is done by reading the user agent from an instance of the `Page` class.  `FrameLoaderClientJava` has a `m_page` field that is lazily initialized whenever it is needed. This lazy initialization can no longer be done from the `userAgent` method, since it is `const`, as can be seen from this change that was done as part of WebKit 610.2:


--- a/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
+++ b/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
-String FrameLoaderClientJava::userAgent(const URL&)
+String FrameLoaderClientJava::userAgent(const URL&) const
 {
-    return page()->settings().userAgent();
+    if (!m_page)
+        return emptyString();
+    return m_page->settings().userAgent();
 }


Formerly, if the `m_page` field was uninitialized, FrameLoaderClient::userAgent would have initialized it by the call to the `page()` function, but since it is now `const` we can't do that. This means that the user agent string will be empty until some other method is called that initializes the `m_page` field.

The fix is to initialize that field when the `WebPage` is created. We can't do it in the constructor, since the needed reference to the `Page` class isn't yet available, so I added an `init` method that is called from `WebPage::twkInit`.

I added a new unit test that fails without the fix and passes with the fix.

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

Commit messages:
 - 8275138: WebView: UserAgent string is empty for first request

Changes: https://git.openjdk.java.net/jfx/pull/643/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=643&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275138
  Stats: 51 lines in 4 files changed: 33 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jfx/pull/643.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/643/head:pull/643

PR: https://git.openjdk.java.net/jfx/pull/643

From kcr at openjdk.java.net  Thu Oct 14 13:07:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 13:07:54 GMT
Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly
In-Reply-To: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
References: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
Message-ID: <HiSp3MZLb6pREwEy_34hLNaZlfJIEmBA65EZRaovodM=.881f33bf-083e-454f-80cf-2253a9057240@github.com>

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race <prr at openjdk.org> wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

The fix itself is simple, but a second pair of eyes would be useful.

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

PR: https://git.openjdk.java.net/jfx/pull/642

From kcr at openjdk.java.net  Thu Oct 14 13:36:53 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 13:36:53 GMT
Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly
In-Reply-To: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
References: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
Message-ID: <1TVzay9_UO8n5JgbE0IKo778AmHgRHYG5nr5CrotqMc=.4093426f-bcf1-4ae8-8a90-3061ab13a701@github.com>

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race <prr at openjdk.org> wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/642

From perini.davide at dpsoftware.org  Thu Oct 14 14:05:43 2021
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Thu, 14 Oct 2021 16:05:43 +0200
Subject: JavaFX, show canvas on second scree, w
Message-ID: <8b0cd909-e0f2-24fa-fc48-e19c14b90d88@dpsoftware.org>

Hi all,
I have a small piece of code that shows a canvas with JavaFX.

I want to display the canvas on the second screen.
This works well in Windows but not on Linux Ubuntu.

Stage stage =new Stage(); Group root =new Group(); Scene s =new Scene(root, 1920, 1080, Color.BLACK); GraphicsContext gc; Canvas canvas =new Canvas(1920,1080); gc = canvas.getGraphicsContext2D(); canvas.setFocusTraversable(true); // Hide canvas on key pressed canvas.setOnKeyPressed(t -> {
     stage.setFullScreen(false); stage.hide(); }); drawThings(gc); root.getChildren().add(canvas); stage.setScene(s); // Show canvas on the second display Rectangle2D bounds = Screen.getScreens().get(1).getVisualBounds(); stage.setX(bounds.getMinX()); stage.setY(bounds.getMinY()); stage.show(); stage.setFullScreen(true);



On Linux the canvas is shown on the first screen.
I have tried swapping the screen index from

// Show canvas on the second display Rectangle2D bounds = Screen.getScreens().get(1).getVisualBounds();

to

// Show canvas on the second display Rectangle2D bounds = Screen.getScreens().get(0).getVisualBounds();

but same problem.

Any idea?

Thank you
Davide









From kcr at openjdk.java.net  Thu Oct 14 14:24:56 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 14:24:56 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v6]
In-Reply-To: <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
Message-ID: <k2uuURl4m7e2c4uiNu40yGSqXZV5aNuL35DtSi2s4nI=.e4020e5e-e384-4a28-a535-97dc1187e4ba@github.com>

On Tue, 28 Sep 2021 12:07:36 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   removed the toggle fullscreen before closing - to avoid the beep and improve the user experience

The latest version of the fix looks better. There is only one remaining problem that I see: If an application calls `Platform.exit()` while in full-screen mode the following exception will be thrown and printed to the console:


Exception in thread "JavaFX Application Thread" java.lang.NullPointerException: Cannot invoke "com.sun.glass.ui.Application.staticScreen_getScreens()" because the return value of "com.sun.glass.ui.Application.GetApplication()" is null
	at javafx.graphics at 18-internal/com.sun.glass.ui.Screen.initScreens(Screen.java:410)
	at javafx.graphics at 18-internal/com.sun.glass.ui.Screen.notifySettingsChanged(Screen.java:379)


This will happen regardless of whether full-screen was entered via the green full-screen button, or by a call to `Stage::setFullScreen(true)`. The easiest way to reproduce this is with the `HelloFullscreen` test program, which is in `apps/toys/Hello`:

1. Run `java hello.HelloFullscreen`
2. Press the `Exit` button.

If instead you either press the `Close` button (which hides the stage) or use the red X in the window decoration, the application closes without throwing the exception.

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

PR: https://git.openjdk.java.net/jfx/pull/622

From kcr at openjdk.java.net  Thu Oct 14 14:30:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 14:30:55 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v6]
In-Reply-To: <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
Message-ID: <DhcX4plLrvNSZ3WxJu2aQW6wcYBHixndp0EnvXrZ8Kk=.c8538ba7-5078-45a4-af9d-547e36df2001@github.com>

On Tue, 28 Sep 2021 12:07:36 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   removed the toggle fullscreen before closing - to avoid the beep and improve the user experience

I spoke too soon. I was running a few other manual tests, and your latest fix completely breaks the normal exit from full screen mode. To reproduce this:

1. Run `java hello.HelloFullscreenToggle`
2. Press the `Toggle Fullscreen` button to enter full-screen mode
3. Try to exit full screen mode, either by pressing the `ESC` key or by pressing the `Toggle Fullscreen` button again.
BUG: you can't exit full-screen mode.

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

PR: https://git.openjdk.java.net/jfx/pull/622

From kcr at openjdk.java.net  Thu Oct 14 14:32:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 14:32:52 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: <GwUj4mH4dnEFsVR8e77nUsErRBCdrgRfFBU_TGKyQ1c=.73ca840a-1b70-4219-81cc-7d7c1b761301@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <GwUj4mH4dnEFsVR8e77nUsErRBCdrgRfFBU_TGKyQ1c=.73ca840a-1b70-4219-81cc-7d7c1b761301@github.com>
Message-ID: <F57dNR7mFD8WeoTsoWzXHLCX6uvNn1zt8x2mH-css-o=.003e7871-1c35-47cd-9871-5e51d3033e5e@github.com>

On Thu, 22 Jul 2021 11:50:11 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.

I don't have a good suggestion at the moment.

Converting this to Draft, since it isn't (yet) ready for review.

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

PR: https://git.openjdk.java.net/jfx/pull/584

From kcr at openjdk.java.net  Thu Oct 14 14:34:54 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 14:34:54 GMT
Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5]
In-Reply-To: <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
References: <rucQpoQckz65kU-gd1XWyNifMwzjSTOz197mwwEKTFQ=.189d92da-7491-42e0-8934-8a62904d6828@github.com>
 <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
Message-ID: <bo3zEU0-Q-Y8ioHPE8ZglgfR8MjuJISxcHZBfq65cus=.4b5c240f-cd26-420b-b748-fb4df63aeea2@github.com>

On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work.  Also added a single JUnit 5 tests, and confirmed it works.
>> 
>> I've updated the Eclipse project file for the base module only.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd junit declaration in allprojects and set junit version to 4.13.2

I'll look at getting the necessary approvals starting next week. It should be relatively straight-forward.

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

PR: https://git.openjdk.java.net/jfx/pull/633

From kcr at openjdk.java.net  Thu Oct 14 14:48:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 14:48:49 GMT
Subject: RFR: 8232812: [MacOS] Double click title bar does not restore
 window size
In-Reply-To: <qr_SAt3FHWg3aC0hK35MCDI3aneS8lCz1D77cSME130=.705c963f-a83c-4ae7-8971-798ac2171bab@github.com>
References: <qr_SAt3FHWg3aC0hK35MCDI3aneS8lCz1D77cSME130=.705c963f-a83c-4ae7-8971-798ac2171bab@github.com>
Message-ID: <Js50oFl9y25v5GysRIBWYNoHC2TvNKKTpkdqor0fQuQ=.372fdd64-ac2e-4a62-8938-eb388fdcd51b@github.com>

On Tue, 5 Oct 2021 20:36:37 GMT, Martin Fox <duke at openjdk.java.net> wrote:

> The test case for JDK-8160241 creates a window in a zoomed state (as defined by macOS). When the OS later goes to unzoom the window it will try to shrink it down to 1 point wide. This was entered as JDK-8163137 but the fix for that bug inadvertently disabled unzooming altogether. This PR fixes 8163137 in a slightly different way.
> 
> Access to the zoom/unzoom feature has changed with newer versions of macOS. To reproduce this you have to change `System Preferences > Dock & Menu Bar > Double-click a window's title bar` to `zoom`. Then use double-clicks in the title bar to test the feature. The green button in the title bar no longer has anything to do with zoom/unzoom.

The proposed change looks good. I confirm that it fixes this bug without reintroducing JDK-8160241.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/639

From nlisker at gmail.com  Thu Oct 14 16:39:23 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 14 Oct 2021 19:39:23 +0300
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <CAJEpuXTJZrhgFp1V_CpGeGGH+jPhTasZ=WP5me7j9zUuoQALiQ@mail.gmail.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CAJEpuXTJZrhgFp1V_CpGeGGH+jPhTasZ=WP5me7j9zUuoQALiQ@mail.gmail.com>
Message-ID: <CA+0ynh8sbQ0Wkz4RQEobYKCsHUTN3NVEaq3adpcyeez6nJ_uzQ@mail.gmail.com>

I disagree with this interpretation. Observable says


> Implementations in this library mark themselves as invalid when the first
> invalidation event occurs. They do not generate anymore invalidation events
> until their value is recomputed and valid again.


And ObservableValue says

An ObservableValue generates two types of events: ... An invalidation event
> is generated if the current value is not valid anymore.


Implementations in this library mark themselves as invalid when the first
> invalidation event occurs. They do not generate any more invalidation
> events until their value is recomputed and valid again.


It's clear that the validity is with respect to the value, not the
listener. There is 1 value and it is either valid or invalid.

If we want to define validity on a per-listener basis, the docs would need
to be changed too. I don't know how much sense it makes practically because
I don't think anyone used them with this intention in mind. It could be a
middleground to bridge the current "negligence"  with the stricter docs,
but it's a more fundamental change conceptually.

On Wed, Oct 6, 2021 at 8:02 PM Michael Strau? <michaelstrau2 at gmail.com>
wrote:

> The documentation of `Observable` states that "an implementation [...]
> may support lazy evaluation" and that "implementations [...] should
> strive to generate as few events as possible".
> This seems to me like it would be within spec to fire an invalidation
> event for every single change. It would also be within spec to fire
> redundant invalidation events only in certain scenarios (like adding a
> listener).
>
> The problem could also be approached from a different angle: what does
> it mean for a property to be "valid"?
> As implemented, the "valid" state is an opaque and unknowable
> implementation detail. We could re-define "valid" to mean: valid from
> the perspective of an InvalidationListener.
> A newly-added InvalidationListener wouldn't know that the property is
> invalid (and has no way of knowing), and can therefore reasonably
> assume that, from its perspective, the property is valid. It would
> receive an invalidation event when the property value is changed.
> From the perspective of pre-existing listeners, however, the property
> could well have been invalid all the time, so they won't receive an
> invalidation event.
>
> On Wed, Oct 6, 2021 at 2:16 AM Kevin Rushforth
> <kevin.rushforth at oracle.com> wrote:
> >
> > Given that the intention of InvalidationListener was to be a
> > light-weight way to listen to properties without causing a binding chain
> > to be revalidated, it does seem reasonable to me that the listener is
> > only fired on the valid --> invalid transition, which is the specified
> > behavior, even if the implementation doesn't currently do that in all
> cases.
> >
> > The two related questions then are:
> >
> > 1. Should adding an invalidation listener to property do an immediate
> > get(), which will ensure that the property is then valid? This will
> > force an eager evaluation of the property and "arm" the property to fire
> > an invalidation even the next time it is invalidated.
> >
> > 2. Should adding an invalidation listener to a currently invalid
> > property cause the listener to be called (either immediately or the next
> > time the object is invalidated)?
> >
> > I think the ideal answer to both questions is "no", although I share
> > John's concern that changing this behavior for InvalidationListeners
> > could break applications. So the question is: how likely do we think
> > that changing this behavior will break existing applications?
> >
> > I think it's something we can and should consider changing. Unless there
> > are serious concerns, I would support changing this behavior as part of
> > avoiding eager evaluation when using invalidation listeners. It would
> > need to be well tested (of course), and would need a CSR describing the
> > compatibility risk, and should probably get a release note.
> >
> > Any concerns in doing this?
> >
> > On the related question, I like the idea of nulling out the current
> > value when a property is bound.
> >
> > -- Kevin
> >
> >
> > On 9/11/2021 9:41 AM, Nir Lisker wrote:
> > > I think that we need your input on this to move it forward.
> > >
> > > On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com
> > > <mailto:nlisker at gmail.com>> wrote:
> > >
> > >         so the value field should perhaps be nulled out when bound.
> > >
> > >
> > >     There was a PR for something like that in the old repo:
> > >     https://github.com/javafxports/openjdk-jfx/pull/110
> > >     <
> https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$
> >
> > >
> > >     On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl
> > >     <mailto:hjohn at xs4all.nl>> wrote:
> > >
> > >
> > >
> > >         On 02/09/2021 11:57, Nir Lisker wrote:
> > >         >     So in order
> > >         >     to make sure that a new interested invalidation listener
> > >         does not miss
> > >         >     the fact that a property was *already* invalid, the
> > >         easiest solution
> > >         >     might have been to revalidate it upon registration of a
> > >         new listener
> > >         >
> > >         >
> > >         > But why does an invalidation listener need to know the past
> > >         state of the
> > >         > property? It is only interested in the valid -> invalid
> > >         transition. If
> > >         > the property was invalid then the listener (in theory)
> > >         shouldn't receive
> > >         > any events anyway on subsequent invalidations. (I understand
> > >         that you
> > >         > don't justify this, I'm posing it as a general question.)
> > >
> > >         Strictly speaking, no, if users are using InvalidationListener
> > >         correctly
> > >         then this is definitely correct behavior. I'm not really
> > >         advocating a
> > >         change, and I'd even prefer that it be brought in line with the
> > >         documentation.
> > >
> > >         I think however that many users are not using it correctly and
> > >         expect an
> > >         invalidation event always the next time the value changes (and
> > >         their
> > >         listener will read that value, validating it again), making it
> > >         act like
> > >         a light-weight ChangeListener. I know that I probably have
> > >         written code
> > >         that made that assumption, and would in the past not even
> > >         think twice
> > >         about replacing a change with an invalidation listener or vice
> > >         versa if
> > >         that happened to be a better fit. Which is sort of what
> > >         happened as well
> > >         in the bidirectional binding PR, and the issue slipped past
> > >         the author
> > >         and two reviewers.
> > >
> > >         > I suggest that we split the problem into 2: one is the case
> > >         where the
> > >         > property was valid when the listener was attached, and the
> > >         other is when
> > >         > it was invalid.
> > >         > * A valid starting state. In this case attaching a listener
> > >         shouldn't
> > >         > need to do anything. A subsequent invalidation event will be
> > >         sent
> > >         > regardless. Currently, it is calling get() redundantly.
> > >
> > >         True, the call to get is redundant in this case. Ugly too,
> > >         calling get
> > >         and discarding its result, while the intention is to force the
> > >         property
> > >         to become valid.
> > >
> > >         > * An invalid starting state. In this case the documentation
> > >         says that
> > >         > nothing needs to happen, but get() is called anyway. Here,
> the
> > >         > difference is that a subsequent invalidation event is sent
> > >         in one case
> > >         > and not in the other. The only way to advance here is to
> > >         make a design
> > >         > decision on what should happen, at least that's how I see it.
> > >
> > >         The docs are even more specific I think, they say no more
> > >         events will be
> > >         generated until it becomes valid -- it doesn't leave any
> > >         option open
> > >         that it could generate events if it wanted to.
> > >
> > >         > As to the implementation of a possible solution, suppose we
> > >         add the
> > >         > isValid method. Upon attaching an invalidation listener, if
> > >         the property
> > >         > is valid, we can skip the get() call. That solves the valid
> > >         starting
> > >         > state issue. The question is what to do if the property is
> > >         not valid.
> > >         >
> > >         > I also noticed an odd design choice in the implementation of
> > >         properties:
> > >         > the value field does not update if the property is bound,
> > >         instead, the
> > >         > result of the binding is returned and the value field holds
> > >         an outdated
> > >         > value (until the property is unbound).
> > >
> > >         Yeah, that might not be a wise decision as that can lead to
> > >         memory being
> > >         referenced that users might expect to be freed. I didn't see
> > >         anywhere
> > >         defined what will happen to the value of the property when it
> > >         is unbound
> > >         again. The current implementation will keep its last value
> > >         (during the
> > >         unbind it will take the last value and assign it to its own
> value
> > >         field), so the value field should perhaps be nulled out when
> > >         bound.
> > >
> > >         --John
> > >
> >
>

From kcr at openjdk.java.net  Thu Oct 14 17:17:55 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 17:17:55 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v6]
In-Reply-To: <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <vO9iQpsfzvHPY2TlQqlyL9iiK997b_wQLlONxha1Ggo=.5fc9a056-284e-4d30-857f-77f6f1306437@github.com>
Message-ID: <k-Jrjdf2pbDumT-LZdVnQ0ec8vrYc5ZzE7oRs8ZHjIA=.7be4379a-215f-4949-9d17-96b6a545f11f@github.com>

On Tue, 28 Sep 2021 12:07:36 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   removed the toggle fullscreen before closing - to avoid the beep and improve the user experience

I think that removing the call to `toggleFullScreen` in `exitFullscreenWithAnimate` is what's causing the failure to exit from fullScreen.

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1349:

> 1347:             [self->nativeFullScreenModeWindow performSelector:@selector(toggleFullScreen:) withObject:nil];
> 1348:             // wait until the operation is complete
> 1349:             [GlassApplication enterFullScreenExitingLoop];

You will need to restore the call to `toggleFullScreen` in order to support exiting from full-screen.

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

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/622

From kcr at openjdk.java.net  Thu Oct 14 17:57:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 17:57:49 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS
In-Reply-To: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
Message-ID: <-qe7eT7J61byfVkOhkgsS3jUT35kfp8NVA_FMzho2Lk=.7696c6b4-b3b2-4043-9255-5e78cd2865d0@github.com>

On Wed, 6 Oct 2021 07:43:15 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
> 
> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
> https://bugs.openjdk.java.net/browse/JDK-8268657
> It also looks different so I don't think this PR fixes this, if it is still there.

The fix and the test look fine with one comment below.

modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 822:

> 820:             int ttype = root.token.getType();
> 821: 
> 822:             if (ttype != CssLexer.STRING && ttype != CssLexer.IDENT || str == null || str.isEmpty()) {

Why did you modify this code? It looks conceptually identical to the previous, but without a check for `root.token == null`. As it is, you will need to prove that `root.token` can never be `null` (I suspect it cannot be, but since `root` is an instance variable you will need to prove that no call earlier in this method can change it as a side effect). I recommend either restoring the previous logic to minimize the diffs of your fix, or else adding a check for `token == null`.

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

PR: https://git.openjdk.java.net/jfx/pull/640

From mhanl at openjdk.java.net  Thu Oct 14 19:52:50 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 14 Oct 2021 19:52:50 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS
In-Reply-To: <-qe7eT7J61byfVkOhkgsS3jUT35kfp8NVA_FMzho2Lk=.7696c6b4-b3b2-4043-9255-5e78cd2865d0@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
 <-qe7eT7J61byfVkOhkgsS3jUT35kfp8NVA_FMzho2Lk=.7696c6b4-b3b2-4043-9255-5e78cd2865d0@github.com>
Message-ID: <VrBkJK_RCSUV9gbaXC6dnUN5qz5fnnjfTGNhiDrA5ss=.426c7bcb-e772-4aea-ba46-51b87db0008f@github.com>

On Thu, 14 Oct 2021 17:45:40 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
>> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
>> 
>> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
>> https://bugs.openjdk.java.net/browse/JDK-8268657
>> It also looks different so I don't think this PR fixes this, if it is still there.
>
> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 822:
> 
>> 820:             int ttype = root.token.getType();
>> 821: 
>> 822:             if (ttype != CssLexer.STRING && ttype != CssLexer.IDENT || str == null || str.isEmpty()) {
> 
> Why did you modify this code? It looks conceptually identical to the previous, but without a check for `root.token == null`. As it is, you will need to prove that `root.token` can never be `null` (I suspect it cannot be, but since `root` is an instance variable you will need to prove that no call earlier in this method can change it as a side effect). I recommend either restoring the previous logic to minimize the diffs of your fix, or else adding a check for `token == null`.

Right, I removed it because it is checked on top of this method (Line 705), and this allowed to tidy the code a bit as this big if condition is quite confusing. But since I will readd the null check, it's probably the best to restore the behaviour.

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

PR: https://git.openjdk.java.net/jfx/pull/640

From mhanl at openjdk.java.net  Thu Oct 14 21:47:16 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 14 Oct 2021 21:47:16 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS [v2]
In-Reply-To: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
Message-ID: <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>

> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
> 
> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
> https://bugs.openjdk.java.net/browse/JDK-8268657
> It also looks different so I don't think this PR fixes this, if it is still there.

Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:

 - 8274699: Revert whitespace
 - 8274699: Revert minor code change

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/640/files
  - new: https://git.openjdk.java.net/jfx/pull/640/files/2a18bf24..302b6425

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=640&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=640&range=00-01

  Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/640.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/640/head:pull/640

PR: https://git.openjdk.java.net/jfx/pull/640

From kcr at openjdk.java.net  Thu Oct 14 22:01:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 14 Oct 2021 22:01:49 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS [v2]
In-Reply-To: <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
 <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
Message-ID: <lv2SAlW3Rr-uPN_3OioJvP2M4LFKob2PTEbIn1CGai8=.e40cba04-5ed7-4d9c-853e-f3620b1b7bcc@github.com>

On Thu, 14 Oct 2021 21:47:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
>> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
>> 
>> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
>> https://bugs.openjdk.java.net/browse/JDK-8268657
>> It also looks different so I don't think this PR fixes this, if it is still there.
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8274699: Revert whitespace
>  - 8274699: Revert minor code change

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/640

From kevin.rushforth at oracle.com  Thu Oct 14 22:06:52 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 14 Oct 2021 15:06:52 -0700
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <CA+0ynh8sbQ0Wkz4RQEobYKCsHUTN3NVEaq3adpcyeez6nJ_uzQ@mail.gmail.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CAJEpuXTJZrhgFp1V_CpGeGGH+jPhTasZ=WP5me7j9zUuoQALiQ@mail.gmail.com>
 <CA+0ynh8sbQ0Wkz4RQEobYKCsHUTN3NVEaq3adpcyeez6nJ_uzQ@mail.gmail.com>
Message-ID: <76249c8b-c31d-a9ee-3fe5-7d57ba361545@oracle.com>

I agree with Nir on this point. I don't see the middle ground as being 
all that useful in practice, just more complicated, and the 
specification change would be odd.

So I think we either go with the proposed change (and it would need to 
be well-tested), or leave it as-is, where every new invalidation 
listener validates the object being listened to. It would be an easy 
call if it weren't for the concern about potentially breaking 
applications that have baked in assumptions on the existing behavior.

-- Kevin


On 10/14/2021 9:39 AM, Nir Lisker wrote:
> I disagree with this interpretation. Observable says
>
>     Implementations in this library mark themselves as invalid when
>     the first invalidation event occurs. They do not generate anymore
>     invalidation events until their value is recomputed and valid again.
>
>
> And ObservableValue says
>
>     An ObservableValue generates two types of events: ... An
>     invalidation event is generated if the current value is not valid
>     anymore.
>
>
>     Implementations in this library mark themselves as invalid when
>     the first invalidation event occurs. They do not generate any more
>     invalidation events until their value is recomputed and valid again.
>
>
> It's clear that the validity is with respect to the value, not the 
> listener. There is 1 value and it is either valid or invalid.
>
> If we want to define validity on a per-listener basis, the docs would 
> need to be changed too. I don't know how much sense it makes 
> practically because I don't think anyone used them with this intention 
> in mind. It could be a middleground to bridge the current 
> "negligence"? with the stricter docs, but it's a more fundamental 
> change conceptually.
>
> On Wed, Oct 6, 2021 at 8:02 PM Michael Strau? <michaelstrau2 at gmail.com 
> <mailto:michaelstrau2 at gmail.com>> wrote:
>
>     The documentation of `Observable` states that "an implementation [...]
>     may support lazy evaluation" and that "implementations [...] should
>     strive to generate as few events as possible".
>     This seems to me like it would be within spec to fire an invalidation
>     event for every single change. It would also be within spec to fire
>     redundant invalidation events only in certain scenarios (like adding a
>     listener).
>
>     The problem could also be approached from a different angle: what does
>     it mean for a property to be "valid"?
>     As implemented, the "valid" state is an opaque and unknowable
>     implementation detail. We could re-define "valid" to mean: valid from
>     the perspective of an InvalidationListener.
>     A newly-added InvalidationListener wouldn't know that the property is
>     invalid (and has no way of knowing), and can therefore reasonably
>     assume that, from its perspective, the property is valid. It would
>     receive an invalidation event when the property value is changed.
>     From the perspective of pre-existing listeners, however, the property
>     could well have been invalid all the time, so they won't receive an
>     invalidation event.
>
>     On Wed, Oct 6, 2021 at 2:16 AM Kevin Rushforth
>     <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>     wrote:
>     >
>     > Given that the intention of InvalidationListener was to be a
>     > light-weight way to listen to properties without causing a
>     binding chain
>     > to be revalidated, it does seem reasonable to me that the
>     listener is
>     > only fired on the valid --> invalid transition, which is the
>     specified
>     > behavior, even if the implementation doesn't currently do that
>     in all cases.
>     >
>     > The two related questions then are:
>     >
>     > 1. Should adding an invalidation listener to property do an
>     immediate
>     > get(), which will ensure that the property is then valid? This will
>     > force an eager evaluation of the property and "arm" the property
>     to fire
>     > an invalidation even the next time it is invalidated.
>     >
>     > 2. Should adding an invalidation listener to a currently invalid
>     > property cause the listener to be called (either immediately or
>     the next
>     > time the object is invalidated)?
>     >
>     > I think the ideal answer to both questions is "no", although I share
>     > John's concern that changing this behavior for InvalidationListeners
>     > could break applications. So the question is: how likely do we think
>     > that changing this behavior will break existing applications?
>     >
>     > I think it's something we can and should consider changing.
>     Unless there
>     > are serious concerns, I would support changing this behavior as
>     part of
>     > avoiding eager evaluation when using invalidation listeners. It
>     would
>     > need to be well tested (of course), and would need a CSR
>     describing the
>     > compatibility risk, and should probably get a release note.
>     >
>     > Any concerns in doing this?
>     >
>     > On the related question, I like the idea of nulling out the current
>     > value when a property is bound.
>     >
>     > -- Kevin
>     >
>     >
>     > On 9/11/2021 9:41 AM, Nir Lisker wrote:
>     > > I think that we need your input on this to move it forward.
>     > >
>     > > On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com
>     <mailto:nlisker at gmail.com>
>     > > <mailto:nlisker at gmail.com <mailto:nlisker at gmail.com>>> wrote:
>     > >
>     > >? ? ? ? ?so the value field should perhaps be nulled out when
>     bound.
>     > >
>     > >
>     > >? ? ?There was a PR for something like that in the old repo:
>     > > https://github.com/javafxports/openjdk-jfx/pull/110
>     <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!dIduEJEBfgG0KXgohDc0mYSolHJl5R1cHpaCQ65ZZM577aoe65cYHAPYNhMJmmtCHBx7$>
>     > >? ?
>     ?<https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$
>     <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>>
>     > >
>     > >? ? ?On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx
>     <hjohn at xs4all.nl <mailto:hjohn at xs4all.nl>
>     > >? ? ?<mailto:hjohn at xs4all.nl <mailto:hjohn at xs4all.nl>>> wrote:
>     > >
>     > >
>     > >
>     > >? ? ? ? ?On 02/09/2021 11:57, Nir Lisker wrote:
>     > >? ? ? ? ?>? ? ?So in order
>     > >? ? ? ? ?>? ? ?to make sure that a new interested invalidation
>     listener
>     > >? ? ? ? ?does not miss
>     > >? ? ? ? ?>? ? ?the fact that a property was *already* invalid, the
>     > >? ? ? ? ?easiest solution
>     > >? ? ? ? ?>? ? ?might have been to revalidate it upon
>     registration of a
>     > >? ? ? ? ?new listener
>     > >? ? ? ? ?>
>     > >? ? ? ? ?>
>     > >? ? ? ? ?> But why does an invalidation listener need to know
>     the past
>     > >? ? ? ? ?state of the
>     > >? ? ? ? ?> property? It is only interested in the valid -> invalid
>     > >? ? ? ? ?transition. If
>     > >? ? ? ? ?> the property was invalid then the listener (in theory)
>     > >? ? ? ? ?shouldn't receive
>     > >? ? ? ? ?> any events anyway on subsequent invalidations. (I
>     understand
>     > >? ? ? ? ?that you
>     > >? ? ? ? ?> don't justify this, I'm posing it as a general
>     question.)
>     > >
>     > >? ? ? ? ?Strictly speaking, no, if users are using
>     InvalidationListener
>     > >? ? ? ? ?correctly
>     > >? ? ? ? ?then this is definitely correct behavior. I'm not really
>     > >? ? ? ? ?advocating a
>     > >? ? ? ? ?change, and I'd even prefer that it be brought in line
>     with the
>     > >? ? ? ? ?documentation.
>     > >
>     > >? ? ? ? ?I think however that many users are not using it
>     correctly and
>     > >? ? ? ? ?expect an
>     > >? ? ? ? ?invalidation event always the next time the value
>     changes (and
>     > >? ? ? ? ?their
>     > >? ? ? ? ?listener will read that value, validating it again),
>     making it
>     > >? ? ? ? ?act like
>     > >? ? ? ? ?a light-weight ChangeListener. I know that I probably have
>     > >? ? ? ? ?written code
>     > >? ? ? ? ?that made that assumption, and would in the past not even
>     > >? ? ? ? ?think twice
>     > >? ? ? ? ?about replacing a change with an invalidation listener
>     or vice
>     > >? ? ? ? ?versa if
>     > >? ? ? ? ?that happened to be a better fit. Which is sort of what
>     > >? ? ? ? ?happened as well
>     > >? ? ? ? ?in the bidirectional binding PR, and the issue slipped
>     past
>     > >? ? ? ? ?the author
>     > >? ? ? ? ?and two reviewers.
>     > >
>     > >? ? ? ? ?> I suggest that we split the problem into 2: one is
>     the case
>     > >? ? ? ? ?where the
>     > >? ? ? ? ?> property was valid when the listener was attached,
>     and the
>     > >? ? ? ? ?other is when
>     > >? ? ? ? ?> it was invalid.
>     > >? ? ? ? ?> * A valid starting state. In this case attaching a
>     listener
>     > >? ? ? ? ?shouldn't
>     > >? ? ? ? ?> need to do anything. A subsequent invalidation event
>     will be
>     > >? ? ? ? ?sent
>     > >? ? ? ? ?> regardless. Currently, it is calling get() redundantly.
>     > >
>     > >? ? ? ? ?True, the call to get is redundant in this case. Ugly too,
>     > >? ? ? ? ?calling get
>     > >? ? ? ? ?and discarding its result, while the intention is to
>     force the
>     > >? ? ? ? ?property
>     > >? ? ? ? ?to become valid.
>     > >
>     > >? ? ? ? ?> * An invalid starting state. In this case the
>     documentation
>     > >? ? ? ? ?says that
>     > >? ? ? ? ?> nothing needs to happen, but get() is called anyway.
>     Here, the
>     > >? ? ? ? ?> difference is that a subsequent invalidation event
>     is sent
>     > >? ? ? ? ?in one case
>     > >? ? ? ? ?> and not in the other. The only way to advance here is to
>     > >? ? ? ? ?make a design
>     > >? ? ? ? ?> decision on what should happen, at least that's how
>     I see it.
>     > >
>     > >? ? ? ? ?The docs are even more specific I think, they say no more
>     > >? ? ? ? ?events will be
>     > >? ? ? ? ?generated until it becomes valid -- it doesn't leave any
>     > >? ? ? ? ?option open
>     > >? ? ? ? ?that it could generate events if it wanted to.
>     > >
>     > >? ? ? ? ?> As to the implementation of a possible solution,
>     suppose we
>     > >? ? ? ? ?add the
>     > >? ? ? ? ?> isValid method. Upon attaching an invalidation
>     listener, if
>     > >? ? ? ? ?the property
>     > >? ? ? ? ?> is valid, we can skip the get() call. That solves
>     the valid
>     > >? ? ? ? ?starting
>     > >? ? ? ? ?> state issue. The question is what to do if the
>     property is
>     > >? ? ? ? ?not valid.
>     > >? ? ? ? ?>
>     > >? ? ? ? ?> I also noticed an odd design choice in the
>     implementation of
>     > >? ? ? ? ?properties:
>     > >? ? ? ? ?> the value field does not update if the property is
>     bound,
>     > >? ? ? ? ?instead, the
>     > >? ? ? ? ?> result of the binding is returned and the value
>     field holds
>     > >? ? ? ? ?an outdated
>     > >? ? ? ? ?> value (until the property is unbound).
>     > >
>     > >? ? ? ? ?Yeah, that might not be a wise decision as that can
>     lead to
>     > >? ? ? ? ?memory being
>     > >? ? ? ? ?referenced that users might expect to be freed. I
>     didn't see
>     > >? ? ? ? ?anywhere
>     > >? ? ? ? ?defined what will happen to the value of the property
>     when it
>     > >? ? ? ? ?is unbound
>     > >? ? ? ? ?again. The current implementation will keep its last value
>     > >? ? ? ? ?(during the
>     > >? ? ? ? ?unbind it will take the last value and assign it to
>     its own value
>     > >? ? ? ? ?field), so the value field should perhaps be nulled
>     out when
>     > >? ? ? ? ?bound.
>     > >
>     > >? ? ? ? ?--John
>     > >
>     >
>


From kevin.rushforth at oracle.com  Thu Oct 14 23:11:53 2021
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 14 Oct 2021 16:11:53 -0700
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <63151262-feed-c406-7165-7a3c08bc0183@xs4all.nl>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CA+0ynh_U041DJvUpFTwf4vNJ9SP29VGQ2=2U5rvHTXjApkLcNg@mail.gmail.com>
 <63151262-feed-c406-7165-7a3c08bc0183@xs4all.nl>
Message-ID: <e1b3e9c8-1c32-0693-123a-260bed48077c@oracle.com>

That's a good idea to dig into the history further. I looked through the 
closed-source repo, and the behavior of calling get to validate the 
observable when adding an InvalidationListener for bindings has been 
there pretty much from the beginning, even before the creation of the 
ExpressionHelper class (in July 2011).

I looked at when InvaldationListeners were added to the Bindings classes 
(in March 2011), and the initial implementation of that method calls 
get() from the InvalidationListener. That was the commit that also added 
the `testAddingListenerWillAlwaysReceiveInvalidationEvent` test methods.

So this was clearly a deliberate design choice from the beginning. I can 
see the rationale for it, but in retrospect it seems an unfortunate choice.

As mentioned already, if we make any change in this area, it will need 
to be very well-tested, and even then we risk breaking applications.

-- Kevin


On 10/6/2021 12:39 AM, John Hendrikx wrote:
> Is it possible to dig in the history of ExpressionHelper a bit 
> further? In git it seems limited to 9 years ago, but in JIRA I found 
> this bug report:
>
> ??? https://bugs.openjdk.java.net/browse/JDK-8119521
>
> It describes an issue where an InvalidationListener is not working 
> correctly (according to the reporter) and where #get must be called to 
> make it behave as expected.? But it turns out this was already fixed 
> -- this specific fix might have been the one that introduced the #get 
> call in ExpressionHelper.
>
> On 06/10/2021 04:38, Nir Lisker wrote:
>> I would also answer "no" to both points. This is also what the docs say.
>>
>> So the question is: how likely do we think that changing this 
>> behavior will
>>> break existing applications?
>>>
>>
>> That's the main question. I tested the JavaFX code with the new behavior
>> and some tests break immediately, though a few I've looked at seemed 
>> to be
>> testing the invalidation listener behavior itself (in their own 
>> context). I
>> don't know what would break outside of the tests. If we go this 
>> route, we
>> might want to create PRs to fix the tests before we actually change
>> the behavior (in contrast to doing it all in the same PR). I think that
>> tests fail in several modules and it might require several people to fix
>> these tests depending on their areas of expertise. Then we would need to
>> test runtime behavior to see what breaks outside of the tests.
>>
>> In my own codebase nothing breaks, but it's relatively small.
>>
>> On the related question, I like the idea of nulling out the current 
>> value
>>> when a property is bound.
>>>
>>
>> I can pick up from where the older PR stopped. It's a simple change.
>>
>> On Wed, Oct 6, 2021 at 3:15 AM Kevin Rushforth 
>> <kevin.rushforth at oracle.com>
>> wrote:
>>
>>> Given that the intention of InvalidationListener was to be a 
>>> light-weight
>>> way to listen to properties without causing a binding chain to be
>>> revalidated, it does seem reasonable to me that the listener is only 
>>> fired
>>> on the valid --> invalid transition, which is the specified 
>>> behavior, even
>>> if the implementation doesn't currently do that in all cases.
>>>
>>> The two related questions then are:
>>>
>>> 1. Should adding an invalidation listener to property do an immediate
>>> get(), which will ensure that the property is then valid? This will 
>>> force
>>> an eager evaluation of the property and "arm" the property to fire an
>>> invalidation even the next time it is invalidated.
>>>
>>> 2. Should adding an invalidation listener to a currently invalid 
>>> property
>>> cause the listener to be called (either immediately or the next time 
>>> the
>>> object is invalidated)?
>>>
>>> I think the ideal answer to both questions is "no", although I share
>>> John's concern that changing this behavior for InvalidationListeners 
>>> could
>>> break applications. So the question is: how likely do we think that
>>> changing this behavior will break existing applications?
>>>
>>> I think it's something we can and should consider changing. Unless 
>>> there
>>> are serious concerns, I would support changing this behavior as part of
>>> avoiding eager evaluation when using invalidation listeners. It 
>>> would need
>>> to be well tested (of course), and would need a CSR describing the
>>> compatibility risk, and should probably get a release note.
>>>
>>> Any concerns in doing this?
>>>
>>> On the related question, I like the idea of nulling out the current 
>>> value
>>> when a property is bound.
>>>
>>> -- Kevin
>>>
>>>
>>> On 9/11/2021 9:41 AM, Nir Lisker wrote:
>>>
>>> I think that we need your input on this to move it forward.
>>>
>>> On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com> wrote:
>>>
>>>> so the value field should perhaps be nulled out when bound.
>>>>
>>>>
>>>> There was a PR for something like that in the old repo:
>>>> https://github.com/javafxports/openjdk-jfx/pull/110
>>>> <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$> 
>>>>
>>>>
>>>> On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 02/09/2021 11:57, Nir Lisker wrote:
>>>>>> ??? So in order
>>>>>> ??? to make sure that a new interested invalidation listener does 
>>>>>> not
>>>>> miss
>>>>>> ??? the fact that a property was *already* invalid, the easiest
>>>>> solution
>>>>>> ??? might have been to revalidate it upon registration of a new
>>>>> listener
>>>>>>
>>>>>>
>>>>>> But why does an invalidation listener need to know the past state of
>>>>> the
>>>>>> property? It is only interested in the valid -> invalid 
>>>>>> transition. If
>>>>>> the property was invalid then the listener (in theory) shouldn't
>>>>> receive
>>>>>> any events anyway on subsequent invalidations. (I understand that 
>>>>>> you
>>>>>> don't justify this, I'm posing it as a general question.)
>>>>>
>>>>> Strictly speaking, no, if users are using InvalidationListener 
>>>>> correctly
>>>>> then this is definitely correct behavior. I'm not really advocating a
>>>>> change, and I'd even prefer that it be brought in line with the
>>>>> documentation.
>>>>>
>>>>> I think however that many users are not using it correctly and 
>>>>> expect an
>>>>> invalidation event always the next time the value changes (and their
>>>>> listener will read that value, validating it again), making it act 
>>>>> like
>>>>> a light-weight ChangeListener. I know that I probably have written 
>>>>> code
>>>>> that made that assumption, and would in the past not even think twice
>>>>> about replacing a change with an invalidation listener or vice 
>>>>> versa if
>>>>> that happened to be a better fit. Which is sort of what happened 
>>>>> as well
>>>>> in the bidirectional binding PR, and the issue slipped past the 
>>>>> author
>>>>> and two reviewers.
>>>>>
>>>>>> I suggest that we split the problem into 2: one is the case where 
>>>>>> the
>>>>>> property was valid when the listener was attached, and the other is
>>>>> when
>>>>>> it was invalid.
>>>>>> * A valid starting state. In this case attaching a listener 
>>>>>> shouldn't
>>>>>> need to do anything. A subsequent invalidation event will be sent
>>>>>> regardless. Currently, it is calling get() redundantly.
>>>>>
>>>>> True, the call to get is redundant in this case. Ugly too, calling 
>>>>> get
>>>>> and discarding its result, while the intention is to force the 
>>>>> property
>>>>> to become valid.
>>>>>
>>>>>> * An invalid starting state. In this case the documentation says 
>>>>>> that
>>>>>> nothing needs to happen, but get() is called anyway. Here, the
>>>>>> difference is that a subsequent invalidation event is sent in one 
>>>>>> case
>>>>>> and not in the other. The only way to advance here is to make a 
>>>>>> design
>>>>>> decision on what should happen, at least that's how I see it.
>>>>>
>>>>> The docs are even more specific I think, they say no more events 
>>>>> will be
>>>>> generated until it becomes valid -- it doesn't leave any option open
>>>>> that it could generate events if it wanted to.
>>>>>
>>>>>> As to the implementation of a possible solution, suppose we add the
>>>>>> isValid method. Upon attaching an invalidation listener, if the
>>>>> property
>>>>>> is valid, we can skip the get() call. That solves the valid starting
>>>>>> state issue. The question is what to do if the property is not 
>>>>>> valid.
>>>>>>
>>>>>> I also noticed an odd design choice in the implementation of
>>>>> properties:
>>>>>> the value field does not update if the property is bound, 
>>>>>> instead, the
>>>>>> result of the binding is returned and the value field holds an 
>>>>>> outdated
>>>>>> value (until the property is unbound).
>>>>>
>>>>> Yeah, that might not be a wise decision as that can lead to memory 
>>>>> being
>>>>> referenced that users might expect to be freed. I didn't see anywhere
>>>>> defined what will happen to the value of the property when it is 
>>>>> unbound
>>>>> again. The current implementation will keep its last value (during 
>>>>> the
>>>>> unbind it will take the last value and assign it to its own value
>>>>> field), so the value field should perhaps be nulled out when bound.
>>>>>
>>>>> --John
>>>>>
>>>>
>>>
>>


From kcr at openjdk.java.net  Fri Oct 15 00:09:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 Oct 2021 00:09:49 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers
In-Reply-To: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
Message-ID: <vMgRHbnj0kd6qFrzffjMRIq76sp8LmVqalh6DaETI5s=.d566ac83-2f51-4b91-9807-e74baba323fd@github.com>

On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Replacements of more immutable collections.
> 
> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.

Marked as reviewed by kcr (Lead).

modules/javafx.web/src/main/java/com/sun/webkit/Utilities.java line 91:

> 89: 
> 90:     // List of packages to reject
> 91:     private static final List<String> PACKAGES_REJECT_LIST = List.of(

After this change, I think the import of `java.util.Arrays` is unused.

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

PR: https://git.openjdk.java.net/jfx/pull/627

From fastegal at openjdk.java.net  Fri Oct 15 10:21:12 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 Oct 2021 10:21:12 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  fixed formatting as suggested in review
  
  and removed unused (by this fix) import in same file

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/638/files
  - new: https://git.openjdk.java.net/jfx/pull/638/files/050a6caa..4f76e1fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/638.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/638/head:pull/638

PR: https://git.openjdk.java.net/jfx/pull/638

From fastegal at openjdk.java.net  Fri Oct 15 10:21:13 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 15 Oct 2021 10:21:13 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <aHJ2PvZhM8Z5HVnJeRBDbs0qVSabsGEmCBrsJ0oeGAw=.6066b293-7e96-4156-ab57-0959f47aec22@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <aHJ2PvZhM8Z5HVnJeRBDbs0qVSabsGEmCBrsJ0oeGAw=.6066b293-7e96-4156-ab57-0959f47aec22@github.com>
Message-ID: <F1AFFR1YqUT6rEjc8zq1sHpQby7o6MWkkSpJ709PkcQ=.ad3e573f-e063-4719-8f53-12f0b4d6a2a9@github.com>

On Wed, 13 Oct 2021 21:25:43 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed formatting as suggested in review
>>   
>>   and removed unused (by this fix) import in same file
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 549:
> 
>> 547:         int editingRow = 1;
>> 548:         cell.updateIndex(editingRow);
>> 549:         TablePosition<?,?> editingCell = new TablePosition<>(table, editingRow, editingColumn);
> 
> Minor: There is a space missing in `<?,?>`

thanks :)

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

PR: https://git.openjdk.java.net/jfx/pull/638

From kcr at openjdk.java.net  Fri Oct 15 12:53:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 Oct 2021 12:53:52 GMT
Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal
 scrolling
In-Reply-To: <TcI0ahDPMkfnL-9QBkLDnKCXhg_QA0ZAB1htDNWjCjQ=.bff3ab4e-238f-45a3-ad21-504e8412819f@github.com>
References: <TcI0ahDPMkfnL-9QBkLDnKCXhg_QA0ZAB1htDNWjCjQ=.bff3ab4e-238f-45a3-ad21-504e8412819f@github.com>
Message-ID: <e4dnTaCmskI5eOAD2Swy-2ajgsWLwZXG9juCsEGK3wc=.5e20d490-8054-4f16-a7cb-f3279ea4e8b3@github.com>

On Thu, 23 Sep 2021 19:01:52 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes an issue which is probably in JavaFX since VirtualFlow exists.
> While horizontal scrolling any VirtualFlow control the left blue border sometimes disappear/gets smaller. (see also image below)
> 
> This can be fixed by **snapping** the scroll bar value (similar like e.g. a **ScrollPane** does). 
> The same needs to be done on the table header as otherwise the column lines might be 1 px off to the cell lines. 
> As a side effect this also fixes that the column lines sometimes get's blurry when horizontal scrolling (see second image).
> 
> While testing with **-Dglass.win.uiScale** I found out that the problem is not fixed for a scale like 1.25 or 1.5, while it is fixed for 1 or 2. The border sometimes disappears only when the snapped value is a decimal number (which obviously does not happen on a scale of 1 or 2), e.g. something like 12.6 but it will never disappear when it's a normal number, so e.g. just 12.
> 
> That's why something like **Math.round(..)** or just a **cast** to an **int** instead of snapping fixes this problem for all scales. I also didn't notice any side effect. But not sure if this the right fix then. 
> How does JavaFX render a **node** when e.g. the x is a decimal number? And does a decimal number make sense (Why we e.g. don't round the value)?
> 
> Another explanation could also be that there is an issue somewhere deep inside the node layout/snapping/Clip/Group/pixel rendering and to simply round/cast the value just fixes the symptom here.
> 
> In any case I'm open for any feedback, help or explaination.
> I'm also glad for anything which might help identify the root cause here, if any.
> 
> ---
> 1.
> ![image](https://user-images.githubusercontent.com/66004280/134562508-bea6ab9d-d3d0-4dbb-b0ce-dc6570a94ed7.png)
> ---
> 2.
> ![image](https://user-images.githubusercontent.com/66004280/134563377-970b4e48-8528-4dad-95fb-fb93780413e8.png)

Given that this doesn't fix the problem when Hi-DPI scaling is in effect, this will need a different solution. See the discussion in [this thread](https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-October/032215.html) on the openjfx-dev mailing list for some considerations regarding Hi-DPI scaling.

Since this PR isn't ready to be reviewed, I'm moving it to Draft.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3082:

> 3080:             double snappedClipX = snapPositionX(clipX);
> 3081:             setLayoutX(-snappedClipX);
> 3082:             clipRect.setLayoutX(snappedClipX);

This is likely not the right place to snap the coordinates to a pixel boundary. This is usually done as part of layout. I'm also skeptical of the fact that you added it to `setClipX` but not `setClipY`.

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

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/630

From nlisker at openjdk.java.net  Fri Oct 15 14:03:51 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 15 Oct 2021 14:03:51 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers
In-Reply-To: <vMgRHbnj0kd6qFrzffjMRIq76sp8LmVqalh6DaETI5s=.d566ac83-2f51-4b91-9807-e74baba323fd@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <vMgRHbnj0kd6qFrzffjMRIq76sp8LmVqalh6DaETI5s=.d566ac83-2f51-4b91-9807-e74baba323fd@github.com>
Message-ID: <sgTMHwdF5TsMwsEXDFa5viCqQbD6s7UIJ-5ys4kuGB0=.2ff1aa47-b654-4355-b433-4e3d88b234f6@github.com>

On Thu, 14 Oct 2021 23:50:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Replacements of more immutable collections.
>> 
>> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.
>
> modules/javafx.web/src/main/java/com/sun/webkit/Utilities.java line 91:
> 
>> 89: 
>> 90:     // List of packages to reject
>> 91:     private static final List<String> PACKAGES_REJECT_LIST = List.of(
> 
> After this change, I think the import of `java.util.Arrays` is unused.

Even more than that one :)

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

PR: https://git.openjdk.java.net/jfx/pull/627

From nlisker at openjdk.java.net  Fri Oct 15 14:24:15 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 15 Oct 2021 14:24:15 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
Message-ID: <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>

> Replacements of more immutable collections.
> 
> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.

Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:

  Removed unused imports

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/627/files
  - new: https://git.openjdk.java.net/jfx/pull/627/files/255a314d..79606579

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=627&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=627&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/627.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/627/head:pull/627

PR: https://git.openjdk.java.net/jfx/pull/627

From nlisker at openjdk.java.net  Fri Oct 15 15:06:50 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 15 Oct 2021 15:06:50 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
Message-ID: <_qjzSdiVsUBQylCkPU7KN41NlAVsag8dhpYhfaKhVEw=.bd905a2d-81fd-4995-8da1-a83a7035911c@github.com>

On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replacements of more immutable collections.
>> 
>> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports

Do you want to do something about `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` that I pointed out in the PR?

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

PR: https://git.openjdk.java.net/jfx/pull/627

From kcr at openjdk.java.net  Fri Oct 15 16:26:00 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 Oct 2021 16:26:00 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <_qjzSdiVsUBQylCkPU7KN41NlAVsag8dhpYhfaKhVEw=.bd905a2d-81fd-4995-8da1-a83a7035911c@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
 <_qjzSdiVsUBQylCkPU7KN41NlAVsag8dhpYhfaKhVEw=.bd905a2d-81fd-4995-8da1-a83a7035911c@github.com>
Message-ID: <AgY9Q6kwEsUtuseoZl3euLzdnunNwnRsp4Gphxdxw18=.8196d069-afbb-477d-b37f-65a8f818e1b5@github.com>

On Fri, 15 Oct 2021 15:04:00 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Do you want to do something about `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` that I pointed out in the PR?

I missed that comment. Where do you see this field? I can't find it anywhere.

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

PR: https://git.openjdk.java.net/jfx/pull/627

From kcr at openjdk.java.net  Fri Oct 15 16:30:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 Oct 2021 16:30:51 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
Message-ID: <CQNdjMc8IZf4I5vMRYTq-SZnhQhkmtyNWmBx_co5wtc=.c448589f-e4a5-4829-8d3a-f6ee1dc064ba@github.com>

On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replacements of more immutable collections.
>> 
>> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/627

From kcr at openjdk.java.net  Fri Oct 15 16:30:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 15 Oct 2021 16:30:51 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <AgY9Q6kwEsUtuseoZl3euLzdnunNwnRsp4Gphxdxw18=.8196d069-afbb-477d-b37f-65a8f818e1b5@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
 <_qjzSdiVsUBQylCkPU7KN41NlAVsag8dhpYhfaKhVEw=.bd905a2d-81fd-4995-8da1-a83a7035911c@github.com>
 <AgY9Q6kwEsUtuseoZl3euLzdnunNwnRsp4Gphxdxw18=.8196d069-afbb-477d-b37f-65a8f818e1b5@github.com>
Message-ID: <XaOxZngLDlNO1BTQipg-iF5bosdvqliqiq6oz6K0uY0=.1ac45bb7-e5ad-46c3-919e-b92fd613f576@github.com>

On Fri, 15 Oct 2021 16:23:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > Do you want to do something about `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` that I pointed out in the PR?
> 
> I missed that comment. Where do you see this field? I can't find it anywhere.

Oh, I see it now. It's in the android sources, which aren't part of the regular build. @johanvos will need to comment.

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

PR: https://git.openjdk.java.net/jfx/pull/627

From prr at openjdk.java.net  Fri Oct 15 19:13:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 15 Oct 2021 19:13:52 GMT
Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly
In-Reply-To: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
References: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
Message-ID: <ek4ixEyoNJeZM5XLIC06A6-PA92r-0y7D9MsBvDsaNw=.471b7648-b3c5-46fa-8bb2-410ef69f1ba0@github.com>

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race <prr at openjdk.org> wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

Any takers for the 2nd reviewer ?
BTW another reason for making this simple and easy to revert (after lots more exploriing than you'd think for what ended up as a small fix) is that this should be backported to the LTS releases ..

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

PR: https://git.openjdk.java.net/jfx/pull/642

From pbansal at openjdk.java.net  Sat Oct 16 06:00:53 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 16 Oct 2021 06:00:53 GMT
Subject: RFR: 8236689: macOS 10.15 Catalina: LCD text renders badly
In-Reply-To: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
References: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
Message-ID: <BmOf-qdDRiyZUrcgWS6it1-Tp04whBppxDvQ8ib_iX4=.05e900ea-a519-4488-9e83-b824f770c565@github.com>

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race <prr at openjdk.org> wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

looks good to me

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

Marked as reviewed by pbansal (Committer).

PR: https://git.openjdk.java.net/jfx/pull/642

From perini.davide at dpsoftware.org  Sat Oct 16 16:41:12 2021
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sat, 16 Oct 2021 18:41:12 +0200
Subject: JavaFX, show canvas on second scree, works well on Windows but
 not on Linux
In-Reply-To: <8b0cd909-e0f2-24fa-fc48-e19c14b90d88@dpsoftware.org>
References: <8b0cd909-e0f2-24fa-fc48-e19c14b90d88@dpsoftware.org>
Message-ID: <c0e1d45b-b4ae-87f9-937b-cf0c0db94a38@dpsoftware.org>

The strange things is that it works perfectly on Windows but not on Linux.
Is this a JavaFX bug?

I tried to format code better to make it more readable...

Stage stage = new Stage();
 ??????? Group root = new Group();
 ??????? Scene s = new Scene(root, 1920, 1080, Color.BLACK);
 ??????? GraphicsContext gc;
 ??????? Canvas canvas = new Canvas(1920,1080);
 ??????? gc = canvas.getGraphicsContext2D();
 ??????? canvas.setFocusTraversable(true);
 ??????? // Hide canvas on key pressed
 ??????? canvas.setOnKeyPressed(t -> {
 ??????????? stage.setFullScreen(false);
 ??????????? stage.hide();
 ??????? });
 ??????? drawThings(gc);
 ??????? root.getChildren().add(canvas);
 ??????? stage.setScene(s);
 ??????? // Show canvas on the correct display number
 ??????? Rectangle2D bounds = Screen.getScreens().get(1).getVisualBounds();
 ??????? stage.setX(bounds.getMinX());
 ??????? stage.setY(bounds.getMinY());
 ??????? stage.show();
 ??????? stage.setFullScreen(true);

Thanks
Davide


Il 14/10/2021 16:05, Davide Perini ha scritto:
> Hi all,
> I have a small piece of code that shows a canvas with JavaFX.
>
> I want to display the canvas on the second screen.
> This works well in Windows but not on Linux Ubuntu.
>
> Stage stage =new Stage(); Group root =new Group(); Scene s =new 
> Scene(root, 1920, 1080, Color.BLACK); GraphicsContext gc; Canvas 
> canvas =new Canvas(1920,1080); gc = canvas.getGraphicsContext2D(); 
> canvas.setFocusTraversable(true); // Hide canvas on key pressed 
> canvas.setOnKeyPressed(t -> {
> ??? stage.setFullScreen(false); stage.hide(); }); drawThings(gc); 
> root.getChildren().add(canvas); stage.setScene(s); // Show canvas on 
> the second display Rectangle2D bounds = 
> Screen.getScreens().get(1).getVisualBounds(); 
> stage.setX(bounds.getMinX()); stage.setY(bounds.getMinY()); 
> stage.show(); stage.setFullScreen(true);
>
>
>
> On Linux the canvas is shown on the first screen.
> I have tried swapping the screen index from
>
> // Show canvas on the second display Rectangle2D bounds = 
> Screen.getScreens().get(1).getVisualBounds();
>
> to
>
> // Show canvas on the second display Rectangle2D bounds = 
> Screen.getScreens().get(0).getVisualBounds();
>
> but same problem.
>
> Any idea?
>
> Thank you
> Davide
>
>
>
>
>
>
>
>


From nlisker at gmail.com  Sun Oct 17 17:25:18 2021
From: nlisker at gmail.com (Nir Lisker)
Date: Sun, 17 Oct 2021 20:25:18 +0300
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <e1b3e9c8-1c32-0693-123a-260bed48077c@oracle.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CA+0ynh_U041DJvUpFTwf4vNJ9SP29VGQ2=2U5rvHTXjApkLcNg@mail.gmail.com>
 <63151262-feed-c406-7165-7a3c08bc0183@xs4all.nl>
 <e1b3e9c8-1c32-0693-123a-260bed48077c@oracle.com>
Message-ID: <CA+0ynh-4uN6ymoHbqqjcea8eO6nN3nThyc+DZQ7a_QeXjc2N3w@mail.gmail.com>

>
> As mentioned already, if we make any change in this area, it will need
> to be very well-tested, and even then we risk breaking applications.
>

I can make the change and can fix some of the tests (which will probably
mean deleting some of them since they explicitly rely on this behavior).
Some tests could be in areas of the code I'm not familiar with.
As for breaking applications, I'm not sure what we're supposed to do. Ask
people if they misused InvalidationListener?



On Fri, Oct 15, 2021 at 2:12 AM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> That's a good idea to dig into the history further. I looked through the
> closed-source repo, and the behavior of calling get to validate the
> observable when adding an InvalidationListener for bindings has been
> there pretty much from the beginning, even before the creation of the
> ExpressionHelper class (in July 2011).
>
> I looked at when InvaldationListeners were added to the Bindings classes
> (in March 2011), and the initial implementation of that method calls
> get() from the InvalidationListener. That was the commit that also added
> the `testAddingListenerWillAlwaysReceiveInvalidationEvent` test methods.
>
> So this was clearly a deliberate design choice from the beginning. I can
> see the rationale for it, but in retrospect it seems an unfortunate choice.
>
> As mentioned already, if we make any change in this area, it will need
> to be very well-tested, and even then we risk breaking applications.
>
> -- Kevin
>
>
> On 10/6/2021 12:39 AM, John Hendrikx wrote:
> > Is it possible to dig in the history of ExpressionHelper a bit
> > further? In git it seems limited to 9 years ago, but in JIRA I found
> > this bug report:
> >
> >     https://bugs.openjdk.java.net/browse/JDK-8119521
> >
> > It describes an issue where an InvalidationListener is not working
> > correctly (according to the reporter) and where #get must be called to
> > make it behave as expected.  But it turns out this was already fixed
> > -- this specific fix might have been the one that introduced the #get
> > call in ExpressionHelper.
> >
> > On 06/10/2021 04:38, Nir Lisker wrote:
> >> I would also answer "no" to both points. This is also what the docs say.
> >>
> >> So the question is: how likely do we think that changing this
> >> behavior will
> >>> break existing applications?
> >>>
> >>
> >> That's the main question. I tested the JavaFX code with the new behavior
> >> and some tests break immediately, though a few I've looked at seemed
> >> to be
> >> testing the invalidation listener behavior itself (in their own
> >> context). I
> >> don't know what would break outside of the tests. If we go this
> >> route, we
> >> might want to create PRs to fix the tests before we actually change
> >> the behavior (in contrast to doing it all in the same PR). I think that
> >> tests fail in several modules and it might require several people to fix
> >> these tests depending on their areas of expertise. Then we would need to
> >> test runtime behavior to see what breaks outside of the tests.
> >>
> >> In my own codebase nothing breaks, but it's relatively small.
> >>
> >> On the related question, I like the idea of nulling out the current
> >> value
> >>> when a property is bound.
> >>>
> >>
> >> I can pick up from where the older PR stopped. It's a simple change.
> >>
> >> On Wed, Oct 6, 2021 at 3:15 AM Kevin Rushforth
> >> <kevin.rushforth at oracle.com>
> >> wrote:
> >>
> >>> Given that the intention of InvalidationListener was to be a
> >>> light-weight
> >>> way to listen to properties without causing a binding chain to be
> >>> revalidated, it does seem reasonable to me that the listener is only
> >>> fired
> >>> on the valid --> invalid transition, which is the specified
> >>> behavior, even
> >>> if the implementation doesn't currently do that in all cases.
> >>>
> >>> The two related questions then are:
> >>>
> >>> 1. Should adding an invalidation listener to property do an immediate
> >>> get(), which will ensure that the property is then valid? This will
> >>> force
> >>> an eager evaluation of the property and "arm" the property to fire an
> >>> invalidation even the next time it is invalidated.
> >>>
> >>> 2. Should adding an invalidation listener to a currently invalid
> >>> property
> >>> cause the listener to be called (either immediately or the next time
> >>> the
> >>> object is invalidated)?
> >>>
> >>> I think the ideal answer to both questions is "no", although I share
> >>> John's concern that changing this behavior for InvalidationListeners
> >>> could
> >>> break applications. So the question is: how likely do we think that
> >>> changing this behavior will break existing applications?
> >>>
> >>> I think it's something we can and should consider changing. Unless
> >>> there
> >>> are serious concerns, I would support changing this behavior as part of
> >>> avoiding eager evaluation when using invalidation listeners. It
> >>> would need
> >>> to be well tested (of course), and would need a CSR describing the
> >>> compatibility risk, and should probably get a release note.
> >>>
> >>> Any concerns in doing this?
> >>>
> >>> On the related question, I like the idea of nulling out the current
> >>> value
> >>> when a property is bound.
> >>>
> >>> -- Kevin
> >>>
> >>>
> >>> On 9/11/2021 9:41 AM, Nir Lisker wrote:
> >>>
> >>> I think that we need your input on this to move it forward.
> >>>
> >>> On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com> wrote:
> >>>
> >>>> so the value field should perhaps be nulled out when bound.
> >>>>
> >>>>
> >>>> There was a PR for something like that in the old repo:
> >>>> https://github.com/javafxports/openjdk-jfx/pull/110
> >>>> <
> https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
>
> >>>>
> >>>>
> >>>> On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 02/09/2021 11:57, Nir Lisker wrote:
> >>>>>>     So in order
> >>>>>>     to make sure that a new interested invalidation listener does
> >>>>>> not
> >>>>> miss
> >>>>>>     the fact that a property was *already* invalid, the easiest
> >>>>> solution
> >>>>>>     might have been to revalidate it upon registration of a new
> >>>>> listener
> >>>>>>
> >>>>>>
> >>>>>> But why does an invalidation listener need to know the past state of
> >>>>> the
> >>>>>> property? It is only interested in the valid -> invalid
> >>>>>> transition. If
> >>>>>> the property was invalid then the listener (in theory) shouldn't
> >>>>> receive
> >>>>>> any events anyway on subsequent invalidations. (I understand that
> >>>>>> you
> >>>>>> don't justify this, I'm posing it as a general question.)
> >>>>>
> >>>>> Strictly speaking, no, if users are using InvalidationListener
> >>>>> correctly
> >>>>> then this is definitely correct behavior. I'm not really advocating a
> >>>>> change, and I'd even prefer that it be brought in line with the
> >>>>> documentation.
> >>>>>
> >>>>> I think however that many users are not using it correctly and
> >>>>> expect an
> >>>>> invalidation event always the next time the value changes (and their
> >>>>> listener will read that value, validating it again), making it act
> >>>>> like
> >>>>> a light-weight ChangeListener. I know that I probably have written
> >>>>> code
> >>>>> that made that assumption, and would in the past not even think twice
> >>>>> about replacing a change with an invalidation listener or vice
> >>>>> versa if
> >>>>> that happened to be a better fit. Which is sort of what happened
> >>>>> as well
> >>>>> in the bidirectional binding PR, and the issue slipped past the
> >>>>> author
> >>>>> and two reviewers.
> >>>>>
> >>>>>> I suggest that we split the problem into 2: one is the case where
> >>>>>> the
> >>>>>> property was valid when the listener was attached, and the other is
> >>>>> when
> >>>>>> it was invalid.
> >>>>>> * A valid starting state. In this case attaching a listener
> >>>>>> shouldn't
> >>>>>> need to do anything. A subsequent invalidation event will be sent
> >>>>>> regardless. Currently, it is calling get() redundantly.
> >>>>>
> >>>>> True, the call to get is redundant in this case. Ugly too, calling
> >>>>> get
> >>>>> and discarding its result, while the intention is to force the
> >>>>> property
> >>>>> to become valid.
> >>>>>
> >>>>>> * An invalid starting state. In this case the documentation says
> >>>>>> that
> >>>>>> nothing needs to happen, but get() is called anyway. Here, the
> >>>>>> difference is that a subsequent invalidation event is sent in one
> >>>>>> case
> >>>>>> and not in the other. The only way to advance here is to make a
> >>>>>> design
> >>>>>> decision on what should happen, at least that's how I see it.
> >>>>>
> >>>>> The docs are even more specific I think, they say no more events
> >>>>> will be
> >>>>> generated until it becomes valid -- it doesn't leave any option open
> >>>>> that it could generate events if it wanted to.
> >>>>>
> >>>>>> As to the implementation of a possible solution, suppose we add the
> >>>>>> isValid method. Upon attaching an invalidation listener, if the
> >>>>> property
> >>>>>> is valid, we can skip the get() call. That solves the valid starting
> >>>>>> state issue. The question is what to do if the property is not
> >>>>>> valid.
> >>>>>>
> >>>>>> I also noticed an odd design choice in the implementation of
> >>>>> properties:
> >>>>>> the value field does not update if the property is bound,
> >>>>>> instead, the
> >>>>>> result of the binding is returned and the value field holds an
> >>>>>> outdated
> >>>>>> value (until the property is unbound).
> >>>>>
> >>>>> Yeah, that might not be a wise decision as that can lead to memory
> >>>>> being
> >>>>> referenced that users might expect to be freed. I didn't see anywhere
> >>>>> defined what will happen to the value of the property when it is
> >>>>> unbound
> >>>>> again. The current implementation will keep its last value (during
> >>>>> the
> >>>>> unbind it will take the last value and assign it to its own value
> >>>>> field), so the value field should perhaps be nulled out when bound.
> >>>>>
> >>>>> --John
> >>>>>
> >>>>
> >>>
> >>
>
>

From duke at openjdk.java.net  Mon Oct 18 03:47:02 2021
From: duke at openjdk.java.net (Abhinay Agarwal)
Date: Mon, 18 Oct 2021 03:47:02 GMT
Subject: [jfx17] RFR: 8275361: Create release notes for JavaFX 17.0.1
Message-ID: <T_p3ChFyqLmKICqc4g-HyR4ZW-z-xAHS6hW2tJY_TPA=.6c9274c2-7172-4b66-8a92-11338997fd37@github.com>

Release notes for 17.0.1

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

Commit messages:
 - Update content to match 15.0.1 release notes
 - 8275361: Create release notes for JavaFX 17.0.1

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

PR: https://git.openjdk.java.net/jfx/pull/644

From fkirmaier at openjdk.java.net  Mon Oct 18 08:20:22 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Mon, 18 Oct 2021 08:20:22 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v7]
In-Reply-To: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
Message-ID: <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>

> When using Swing it's possible to generate a Deadlock.
>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>  Sample Programm and Threaddump are added to the ticket.
> 
> Removing the nested loop fixes the Problem. 
> I hope this doesn't have any side effect - so far i don't know of any.

Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8273485
  Fixing toggle fullscreen!

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/622/files
  - new: https://git.openjdk.java.net/jfx/pull/622/files/e263f379..4dcbcc22

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=622&range=05-06

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

PR: https://git.openjdk.java.net/jfx/pull/622

From kcr at openjdk.java.net  Mon Oct 18 12:08:52 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 18 Oct 2021 12:08:52 GMT
Subject: [jfx17] RFR: 8275361: Create release notes for JavaFX 17.0.1
In-Reply-To: <T_p3ChFyqLmKICqc4g-HyR4ZW-z-xAHS6hW2tJY_TPA=.6c9274c2-7172-4b66-8a92-11338997fd37@github.com>
References: <T_p3ChFyqLmKICqc4g-HyR4ZW-z-xAHS6hW2tJY_TPA=.6c9274c2-7172-4b66-8a92-11338997fd37@github.com>
Message-ID: <2uhlGfib3CRatuDLYV6K2E6oi9pOv98A0inkTXyS4OU=.0c441da2-5382-4dcf-ad6d-9860ffb2eaf4@github.com>

On Mon, 18 Oct 2021 03:42:37 GMT, Abhinay Agarwal <duke at openjdk.java.net> wrote:

> Release notes for 17.0.1

@abhinayagarwal This should be done as a PR in the [openjdk/jfx17u](https://github.com/openjdk/jfx17u) repo, which is the repo we use for JavaFX 17 update releases. You will need to close this PR and create a new on in that repo.

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

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/644

From duke at openjdk.java.net  Mon Oct 18 12:33:55 2021
From: duke at openjdk.java.net (Abhinay Agarwal)
Date: Mon, 18 Oct 2021 12:33:55 GMT
Subject: [jfx17] Withdrawn: 8275361: Create release notes for JavaFX 17.0.1
In-Reply-To: <T_p3ChFyqLmKICqc4g-HyR4ZW-z-xAHS6hW2tJY_TPA=.6c9274c2-7172-4b66-8a92-11338997fd37@github.com>
References: <T_p3ChFyqLmKICqc4g-HyR4ZW-z-xAHS6hW2tJY_TPA=.6c9274c2-7172-4b66-8a92-11338997fd37@github.com>
Message-ID: <ewvdJNdF09F4vl7ILHvSpHxE-Zjg-JTsobN2rs0WG68=.75da5353-e927-450b-a380-baf9705185b7@github.com>

On Mon, 18 Oct 2021 03:42:37 GMT, Abhinay Agarwal <duke at openjdk.java.net> wrote:

> Release notes for 17.0.1

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jfx/pull/644

From duke at openjdk.java.net  Mon Oct 18 13:07:06 2021
From: duke at openjdk.java.net (Abhinay Agarwal)
Date: Mon, 18 Oct 2021 13:07:06 GMT
Subject: [jfx17u] RFR: 8275361: Create release notes for JavaFX 17.0.1
Message-ID: <h7D-cCatDPKZJLxmjAkTj2UxaPA5krpE_g1vHVqpLww=.21e2ac1c-0571-4967-aa28-85e821813d6f@github.com>

Release Notes for 17.0.1

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

Commit messages:
 - 8275361: Create release notes for JavaFX 17.0.1

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

PR: https://git.openjdk.java.net/jfx17u/pull/14

From kcr at openjdk.java.net  Mon Oct 18 13:07:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 18 Oct 2021 13:07:06 GMT
Subject: [jfx17u] RFR: 8275361: Create release notes for JavaFX 17.0.1
In-Reply-To: <h7D-cCatDPKZJLxmjAkTj2UxaPA5krpE_g1vHVqpLww=.21e2ac1c-0571-4967-aa28-85e821813d6f@github.com>
References: <h7D-cCatDPKZJLxmjAkTj2UxaPA5krpE_g1vHVqpLww=.21e2ac1c-0571-4967-aa28-85e821813d6f@github.com>
Message-ID: <tRrpIoY44Hm4juX6n0v1sq_XSFeA-njulObteP0RMSg=.07d16e89-42fd-4ce1-9416-6da0004fd45a@github.com>

On Mon, 18 Oct 2021 12:59:17 GMT, Abhinay Agarwal <duke at openjdk.java.net> wrote:

> Release Notes for 17.0.1

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx17u/pull/14

From pedro.duquevieira at gmail.com  Mon Oct 18 14:44:45 2021
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 18 Oct 2021 15:44:45 +0100
Subject: Enhancements for JavaFX 18
In-Reply-To: <CAAEud6aYBRyW_+Y7Ai8h6-Y6vJEsXjdRrYq1m0ZBAZ=tyc6DzA@mail.gmail.com>
References: <CAAEud6Zfy1rAJa-QNyuCL+8KajEbMMiYPZwRRHfHS5f-_4Qj5g@mail.gmail.com>
 <440d16d9-73ef-5c7b-e97d-6b94760f99f7@oracle.com>
 <CAAEud6Y0ArgssX-=L+o8EVc4cp0Ok7TSDrzT1=mCg1YMMvsDig@mail.gmail.com>
 <5678932c-03be-5c32-6e29-ec6f3bc712fc@oracle.com>
 <CAAEud6ZVJcwuAAp3-LOc__S0uXAEqrM-Ke4QKAykwkTh1m4z1A@mail.gmail.com>
 <CAAEud6aYBRyW_+Y7Ai8h6-Y6vJEsXjdRrYq1m0ZBAZ=tyc6DzA@mail.gmail.com>
Message-ID: <CAAEud6ZOvw4fe8xxJHg+2nK-Q51bgXVR3nn_wDATZeC5kUoyYw@mail.gmail.com>

Hi again all,

I ended up not getting a follow up response.

Now that the Mac OS font rendering issue is taken care of, would it perhaps
be possible to look into this? Maybe it's just a quick fix as was the case
of Mac? That would be great if that's the case.

I believe this issue is very important as poor font rendering can
significantly impact the overall look of an app and Windows is still by far
the most used Operating System on Desktop.

Some tricks can improve the rendering on Windows
like: System.setProperty("prism.lcdtext", "false");
But on some cases (when you use bigger text, I think), even with that tweak
the quality of the font rendering can be poor.

Thanks again! Kind regards,

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Aug 11, 2021 at 4:17 PM Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:

> .. on one client project I'm involved in, I ended up having to use a
> static image instead of rendering the text through JavaFX because of the
> difference in text rendering quality.
>
> On Wed, Aug 11, 2021 at 4:14 PM Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
>> OK thanks Phillip!
>>
>> Sorry, I might not have done the best job in reporting the issue
>> back then (it's been a while, it was in 2014) :-)
>>
>> I have an example of the exact same Segoe UI font. One is from Photoshop
>> using the text tool with a selected font and the other is from a JavaFX
>> using the same font. The difference is very noticeable.
>> Would you be interested in seeing the two pictures? If so, how can I
>> share them?
>>
>> Thanks again,
>>
>> On Tue, Aug 10, 2021 at 5:50 PM Philip Race <philip.race at oracle.com>
>> wrote:
>>
>>> Well .. if you know you were the reporter, then it narrows down the JBS
>>> search from thousands to less than 10 :-)
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8092298
>>>
>>> Near as I can tell, that is an issue where we are comparing the FX use
>>> of DirectWrite with
>>> unknown usage and configuration of some Windows bundled apps and maybe
>>> we aren't
>>> even sure it is the same font ..  there was a lot of back and forth
>>> there.
>>>
>>> -phil.
>>>
>>> On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
>>>
>>> I've filed the bug a long time ago so I can't remember exactly the bug
>>> ID or the title I gave it.
>>>
>>> Do you want me to file a new one? Do you want me to attach sample images
>>> (I think you need to do some work around to attach images to a javafx bug
>>> report?)?
>>>
>>> Thanks Philip
>>>
>>> On Mon, Aug 9, 2021 at 4:06 PM Philip Race <philip.race at oracle.com>
>>> wrote:
>>>
>>>> That would be a separate piece of work.  I can't imagine much if any
>>>> overlap.
>>>> Is there a useful bug ID for what you are referring to ?
>>>> The glyph images come from DirectWrite on Windows so I am not sure if
>>>> there's something specific ..
>>>>
>>>> -phil.
>>>>
>>>> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:
>>>>
>>>> Hi!
>>>>
>>>> @Phil Race <philip.race at oracle.com> If you're going to tackle font
>>>> rendering, would it also be possible to work on Windows font rendering? I
>>>> find that Windows font rendering is generally much worse than Mac's.
>>>>
>>>> One example is, for instance, trying to render "Segoe UI" (the Windows
>>>> default font) , or "Segoe UI Light"  font (or whatever variant) with a big
>>>> font size. The font appears pixelated..
>>>>
>>>> Thanks,
>>>>
>>>>
>>>>> +1. It is something I intend to get to for 18.
>>>>
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
>>>>> > May I humbly suggest fixing font rendering color fringe issues on
>>>>> macOS
>>>>
>>>>
>>>> --
>>>> Pedro Duque Vieira - https://www.pixelduke.com
>>>>
>>>>
>>>>
>>>
>>> --
>>> Pedro Duque Vieira - https://www.pixelduke.com
>>>
>>>
>>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From duke at openjdk.java.net  Tue Oct 19 07:52:51 2021
From: duke at openjdk.java.net (Abhinay Agarwal)
Date: Tue, 19 Oct 2021 07:52:51 GMT
Subject: [jfx17u] Integrated: 8275361: Create release notes for JavaFX 17.0.1
In-Reply-To: <h7D-cCatDPKZJLxmjAkTj2UxaPA5krpE_g1vHVqpLww=.21e2ac1c-0571-4967-aa28-85e821813d6f@github.com>
References: <h7D-cCatDPKZJLxmjAkTj2UxaPA5krpE_g1vHVqpLww=.21e2ac1c-0571-4967-aa28-85e821813d6f@github.com>
Message-ID: <AW43RPtNcYGkKz877BQ_9EZ4gy1VqYt_Uo04KXfqFGY=.f66bf7ac-6508-4298-bffa-725a06b9ca6d@github.com>

On Mon, 18 Oct 2021 12:59:17 GMT, Abhinay Agarwal <duke at openjdk.java.net> wrote:

> Release Notes for 17.0.1

This pull request has now been integrated.

Changeset: 23545b4f
Author:    Abhinay Agarwal <abhinay.agarwal at gluonhq.com>
Committer: Johan Vos <jvos at openjdk.org>
URL:       https://git.openjdk.java.net/jfx17u/commit/23545b4fb3d963a052ad81452e06ac71a718a3e4
Stats:     23 lines in 1 file changed: 23 ins; 0 del; 0 mod

8275361: Create release notes for JavaFX 17.0.1

Reviewed-by: kcr

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

PR: https://git.openjdk.java.net/jfx17u/pull/14

From mhanl at openjdk.java.net  Tue Oct 19 09:52:55 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 19 Oct 2021 09:52:55 GMT
Subject: RFR: 8218745: TableView: visual glitch at borders on horizontal
 scrolling
In-Reply-To: <e4dnTaCmskI5eOAD2Swy-2ajgsWLwZXG9juCsEGK3wc=.5e20d490-8054-4f16-a7cb-f3279ea4e8b3@github.com>
References: <TcI0ahDPMkfnL-9QBkLDnKCXhg_QA0ZAB1htDNWjCjQ=.bff3ab4e-238f-45a3-ad21-504e8412819f@github.com>
 <e4dnTaCmskI5eOAD2Swy-2ajgsWLwZXG9juCsEGK3wc=.5e20d490-8054-4f16-a7cb-f3279ea4e8b3@github.com>
Message-ID: <FbeF70AQkBQDjmyT2QJRTEsupwlz7A0MT_DaGETCZZw=.b4526414-0f15-468d-a3b3-1e1d68cea83e@github.com>

On Fri, 24 Sep 2021 12:42:31 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This PR fixes an issue which is probably in JavaFX since VirtualFlow exists.
>> While horizontal scrolling any VirtualFlow control the left blue border sometimes disappear/gets smaller. (see also image below)
>> 
>> This can be fixed by **snapping** the scroll bar value (similar like e.g. a **ScrollPane** does). 
>> The same needs to be done on the table header as otherwise the column lines might be 1 px off to the cell lines. 
>> As a side effect this also fixes that the column lines sometimes get's blurry when horizontal scrolling (see second image).
>> 
>> While testing with **-Dglass.win.uiScale** I found out that the problem is not fixed for a scale like 1.25 or 1.5, while it is fixed for 1 or 2. The border sometimes disappears only when the snapped value is a decimal number (which obviously does not happen on a scale of 1 or 2), e.g. something like 12.6 but it will never disappear when it's a normal number, so e.g. just 12.
>> 
>> That's why something like **Math.round(..)** or just a **cast** to an **int** instead of snapping fixes this problem for all scales. I also didn't notice any side effect. But not sure if this the right fix then. 
>> How does JavaFX render a **node** when e.g. the x is a decimal number? And does a decimal number make sense (Why we e.g. don't round the value)?
>> 
>> Another explanation could also be that there is an issue somewhere deep inside the node layout/snapping/Clip/Group/pixel rendering and to simply round/cast the value just fixes the symptom here.
>> 
>> In any case I'm open for any feedback, help or explaination.
>> I'm also glad for anything which might help identify the root cause here, if any.
>> 
>> ---
>> 1.
>> ![image](https://user-images.githubusercontent.com/66004280/134562508-bea6ab9d-d3d0-4dbb-b0ce-dc6570a94ed7.png)
>> ---
>> 2.
>> ![image](https://user-images.githubusercontent.com/66004280/134563377-970b4e48-8528-4dad-95fb-fb93780413e8.png)
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java line 3082:
> 
>> 3080:             double snappedClipX = snapPositionX(clipX);
>> 3081:             setLayoutX(-snappedClipX);
>> 3082:             clipRect.setLayoutX(snappedClipX);
> 
> This is likely not the right place to snap the coordinates to a pixel boundary. This is usually done as part of layout. I'm also skeptical of the fact that you added it to `setClipX` but not `setClipY`.

I didn't set **clipY** because it's not part of the story and **clipY** is always set to 0 when the `VirtualFlow` is vertical (which is the default for all `VirtualFlowContainer`. Only `ListView` **can** be non-vertical - This should be another bug and test case). That's why there is no issue with it normally.

I'm not sure if this is the wrong place. E.g. `ScrollPaneSkin` also listens on the scrollbar **valueProperty** and sets the **snapped** scrollbar value with **setLayoutX** - which is very similar then here. We set the **layoutX** here as well (for clip and the container).

Finally: While I understand it does not fix every scale, isn't it at least a good first step? (When we agree this is the correct location here)

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

PR: https://git.openjdk.java.net/jfx/pull/630

From aghaisas at openjdk.java.net  Tue Oct 19 12:01:54 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 19 Oct 2021 12:01:54 GMT
Subject: RFR: 8275138: WebView: UserAgent string is empty for first request
In-Reply-To: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
References: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
Message-ID: <trYdJsgPay3gMWTI1Xlp31AYeBYQnWhwaRkrgJr1rzI=.f46002c5-3c5f-412c-a0a8-aa8cc37ece00@github.com>

On Thu, 14 Oct 2021 12:32:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The failure was caused by a change that was done in connection with the WebKit 610.2 update, [JDK-8259635](https://bugs.openjdk.java.net/browse/JDK-8259635). The `FrameLoaderClient::userAgent` function was changed in WebKit itself to be a const method in WebKit 610.2. We override that method in `FrameLoaderClientJava` to return the user agent string, which is done by reading the user agent from an instance of the `Page` class.  `FrameLoaderClientJava` has a `m_page` field that is lazily initialized whenever it is needed. This lazy initialization can no longer be done from the `userAgent` method, since it is `const`, as can be seen from this change that was done as part of WebKit 610.2:
> 
> 
> --- a/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> +++ b/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> -String FrameLoaderClientJava::userAgent(const URL&)
> +String FrameLoaderClientJava::userAgent(const URL&) const
>  {
> -    return page()->settings().userAgent();
> +    if (!m_page)
> +        return emptyString();
> +    return m_page->settings().userAgent();
>  }
> 
> 
> Formerly, if the `m_page` field was uninitialized, FrameLoaderClient::userAgent would have initialized it by the call to the `page()` function, but since it is now `const` we can't do that. This means that the user agent string will be empty until some other method is called that initializes the `m_page` field.
> 
> The fix is to initialize that field when the `WebPage` is created. We can't do it in the constructor, since the needed reference to the `Page` class isn't yet available, so I added an `init` method that is called from `WebPage::twkInit`.
> 
> I added a new unit test that fails without the fix and passes with the fix.

Marked as reviewed by aghaisas (Reviewer).

The fix looks fine. I built and tested on mac.
The new test fails without the fix and passes with it.

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

PR: https://git.openjdk.java.net/jfx/pull/643

From arapte at openjdk.java.net  Wed Oct 20 09:54:09 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 20 Oct 2021 09:54:09 GMT
Subject: RFR: 8275138: WebView: UserAgent string is empty for first request
In-Reply-To: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
References: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
Message-ID: <Bql40gb9AUV-AEiFqIqDrhUVHDxQOkRXy_OfpicVF2Q=.f047edb9-97cd-4aa8-ba1d-6e29b749fc0e@github.com>

On Thu, 14 Oct 2021 12:32:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The failure was caused by a change that was done in connection with the WebKit 610.2 update, [JDK-8259635](https://bugs.openjdk.java.net/browse/JDK-8259635). The `FrameLoaderClient::userAgent` function was changed in WebKit itself to be a const method in WebKit 610.2. We override that method in `FrameLoaderClientJava` to return the user agent string, which is done by reading the user agent from an instance of the `Page` class.  `FrameLoaderClientJava` has a `m_page` field that is lazily initialized whenever it is needed. This lazy initialization can no longer be done from the `userAgent` method, since it is `const`, as can be seen from this change that was done as part of WebKit 610.2:
> 
> 
> --- a/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> +++ b/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> -String FrameLoaderClientJava::userAgent(const URL&)
> +String FrameLoaderClientJava::userAgent(const URL&) const
>  {
> -    return page()->settings().userAgent();
> +    if (!m_page)
> +        return emptyString();
> +    return m_page->settings().userAgent();
>  }
> 
> 
> Formerly, if the `m_page` field was uninitialized, FrameLoaderClient::userAgent would have initialized it by the call to the `page()` function, but since it is now `const` we can't do that. This means that the user agent string will be empty until some other method is called that initializes the `m_page` field.
> 
> The fix is to initialize that field when the `WebPage` is created. We can't do it in the constructor, since the needed reference to the `Page` class isn't yet available, so I added an `init` method that is called from `WebPage::twkInit`.
> 
> I added a new unit test that fails without the fix and passes with the fix.

looks good to me too.

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

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/643

From arapte at openjdk.java.net  Wed Oct 20 11:59:28 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 20 Oct 2021 11:59:28 GMT
Subject: RFR: 8274413: FX: Update copyright year in docs, readme files to 2022
Message-ID: <Xra5wg-Pqq4Z7SxLDD6utrlqDVsckbANzzGi8Kw7O_4=.5167d1bf-d35a-4b4f-9188-1ebd6aec50cf@github.com>

Copyright year in these 3 docs needs to be updated to 2022.

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

Commit messages:
 - copyright year to 2022

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

PR: https://git.openjdk.java.net/jfx/pull/645

From kcr at openjdk.java.net  Wed Oct 20 13:14:06 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 Oct 2021 13:14:06 GMT
Subject: RFR: 8274413: FX: Update copyright year in docs,
 readme files to 2022
In-Reply-To: <Xra5wg-Pqq4Z7SxLDD6utrlqDVsckbANzzGi8Kw7O_4=.5167d1bf-d35a-4b4f-9188-1ebd6aec50cf@github.com>
References: <Xra5wg-Pqq4Z7SxLDD6utrlqDVsckbANzzGi8Kw7O_4=.5167d1bf-d35a-4b4f-9188-1ebd6aec50cf@github.com>
Message-ID: <U_WmnXs6NqhggSw8BnKbNI6mJMl1d6wLpFRsoGxYFbw=.94fac17c-0473-4158-aa5c-827f369df6fa@github.com>

On Wed, 20 Oct 2021 11:53:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Copyright year in these 3 docs needs to be updated to 2022.

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/645

From michaelstrau2 at gmail.com  Wed Oct 20 13:49:50 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 20 Oct 2021 15:49:50 +0200
Subject: [External] : Re: Eager Evaluation of Invalidation Listeners
In-Reply-To: <CA+0ynh8sbQ0Wkz4RQEobYKCsHUTN3NVEaq3adpcyeez6nJ_uzQ@mail.gmail.com>
References: <CA+0ynh-Gxo8q8BhheRr1E4K-Nkzf667K+ygAn-jShYZ-XVcwrw@mail.gmail.com>
 <63aa7a0f-17c1-a6de-eb10-eead56f5743a@xs4all.nl>
 <CA+0ynh_KeWAFzM1017WKX4PJowMmG9ceGe2=gnfbDCFn-RWrZA@mail.gmail.com>
 <a45e0466-5527-2932-b598-839cce40b897@xs4all.nl>
 <CA+0ynh_pFEKc7BV0ozns1-b4=vhgmiCmFgx-CBoBC_YAV2bwNA@mail.gmail.com>
 <CA+0ynh_nkbjLgidf7pihseH9anisMZdSDygFgv=xhkbtpkCi5w@mail.gmail.com>
 <cc364a83-5eb1-3f44-5125-ae1243f4b7be@oracle.com>
 <CAJEpuXTJZrhgFp1V_CpGeGGH+jPhTasZ=WP5me7j9zUuoQALiQ@mail.gmail.com>
 <CA+0ynh8sbQ0Wkz4RQEobYKCsHUTN3NVEaq3adpcyeez6nJ_uzQ@mail.gmail.com>
Message-ID: <CAJEpuXQF7H5ybr5aXyNOLqCtTpUrMNXaKOknng2eAU6n=P_ZvQ@mail.gmail.com>

1) The specification of Observable states that: "An implementation of
{@code Observable} may support lazy evaluation [...]"

It seems to me that this is an optional feature, and a user of this
API must be aware that any particular Observable implementation may
not support it, or that it chooses to implement a custom strategy to
reduce the number of invalidation events ("[...] should strive to
generate as few events as possible").

This means that a user of this API must expect that any particular
Observable implementation may generate an invalidation event for every
single change, or for changes in particular situations (for example,
after an InvalidationListener was added).

Let me summarize that as follows: Any well-behaved listener must
tolerate any lazy evaluation strategy.

I think this is important, because the "problem" that is being
discussed here can't, by definition, cause incorrect behavior for
users of the API.

2) Currently, adding an InvalidationListener validates the property.
This has implications on what I would see as "local reasoning" vs.
"global reasoning": developers can reason about their code in
isolation, and will generally get it right. Changing it means that
whether some listener code works can be dependent on other parts of
the system (parts that might validate the property, such that the
listener code will "accidentally" pick up the next change to the
property).

>From an API standpoint, I would consider this an unfortunate situation
because in many scenarios it will "just work" and not prompt any
further consideration from developers, even though the code that set
up the listener was incorrectly implemented. That's because a correct
implementation would be similar to the following "protocol":

prop.addListener(observable -> { ... prop.getValue(); ... });
prop.getValue();

Any code that doesn't use this protocol to set up an
InvalidationListener is now potentially incorrectly implemented, and
accidental validation will obscure this defect in most cases. Sure, we
can include this information in the specification of Observable, but
this is so easy to get wrong that even with explicitly mentioning it,
developers will routinely get it wrong. This makes for brittle
codebases and obscure defects, where changes to one part of a system
can unexpectedly and silently affect other parts of the system.

We can avoid all of that by changing the specification as follows: If
an Observable implementation supports lazy evaluation, it must not
elide an invalidation event after new listeners have been added.



On Thu, Oct 14, 2021 at 6:39 PM Nir Lisker <nlisker at gmail.com> wrote:
>
> I disagree with this interpretation. Observable says
>
>>
>> Implementations in this library mark themselves as invalid when the first invalidation event occurs. They do not generate anymore invalidation events until their value is recomputed and valid again.
>
>
> And ObservableValue says
>
>> An ObservableValue generates two types of events: ... An invalidation event is generated if the current value is not valid anymore.
>
>
>> Implementations in this library mark themselves as invalid when the first invalidation event occurs. They do not generate any more invalidation events until their value is recomputed and valid again.
>
>
> It's clear that the validity is with respect to the value, not the listener. There is 1 value and it is either valid or invalid.
>
> If we want to define validity on a per-listener basis, the docs would need to be changed too. I don't know how much sense it makes practically because I don't think anyone used them with this intention in mind. It could be a middleground to bridge the current "negligence"  with the stricter docs, but it's a more fundamental change conceptually.
>
> On Wed, Oct 6, 2021 at 8:02 PM Michael Strau? <michaelstrau2 at gmail.com> wrote:
>>
>> The documentation of `Observable` states that "an implementation [...]
>> may support lazy evaluation" and that "implementations [...] should
>> strive to generate as few events as possible".
>> This seems to me like it would be within spec to fire an invalidation
>> event for every single change. It would also be within spec to fire
>> redundant invalidation events only in certain scenarios (like adding a
>> listener).
>>
>> The problem could also be approached from a different angle: what does
>> it mean for a property to be "valid"?
>> As implemented, the "valid" state is an opaque and unknowable
>> implementation detail. We could re-define "valid" to mean: valid from
>> the perspective of an InvalidationListener.
>> A newly-added InvalidationListener wouldn't know that the property is
>> invalid (and has no way of knowing), and can therefore reasonably
>> assume that, from its perspective, the property is valid. It would
>> receive an invalidation event when the property value is changed.
>> From the perspective of pre-existing listeners, however, the property
>> could well have been invalid all the time, so they won't receive an
>> invalidation event.
>>
>> On Wed, Oct 6, 2021 at 2:16 AM Kevin Rushforth
>> <kevin.rushforth at oracle.com> wrote:
>> >
>> > Given that the intention of InvalidationListener was to be a
>> > light-weight way to listen to properties without causing a binding chain
>> > to be revalidated, it does seem reasonable to me that the listener is
>> > only fired on the valid --> invalid transition, which is the specified
>> > behavior, even if the implementation doesn't currently do that in all cases.
>> >
>> > The two related questions then are:
>> >
>> > 1. Should adding an invalidation listener to property do an immediate
>> > get(), which will ensure that the property is then valid? This will
>> > force an eager evaluation of the property and "arm" the property to fire
>> > an invalidation even the next time it is invalidated.
>> >
>> > 2. Should adding an invalidation listener to a currently invalid
>> > property cause the listener to be called (either immediately or the next
>> > time the object is invalidated)?
>> >
>> > I think the ideal answer to both questions is "no", although I share
>> > John's concern that changing this behavior for InvalidationListeners
>> > could break applications. So the question is: how likely do we think
>> > that changing this behavior will break existing applications?
>> >
>> > I think it's something we can and should consider changing. Unless there
>> > are serious concerns, I would support changing this behavior as part of
>> > avoiding eager evaluation when using invalidation listeners. It would
>> > need to be well tested (of course), and would need a CSR describing the
>> > compatibility risk, and should probably get a release note.
>> >
>> > Any concerns in doing this?
>> >
>> > On the related question, I like the idea of nulling out the current
>> > value when a property is bound.
>> >
>> > -- Kevin
>> >
>> >
>> > On 9/11/2021 9:41 AM, Nir Lisker wrote:
>> > > I think that we need your input on this to move it forward.
>> > >
>> > > On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker <nlisker at gmail.com
>> > > <mailto:nlisker at gmail.com>> wrote:
>> > >
>> > >         so the value field should perhaps be nulled out when bound.
>> > >
>> > >
>> > >     There was a PR for something like that in the old repo:
>> > >     https://github.com/javafxports/openjdk-jfx/pull/110
>> > >     <https://urldefense.com/v3/__https://github.com/javafxports/openjdk-jfx/pull/110__;!!ACWV5N9M2RV99hQ!bIbtLsC0tg02c9a_lgKnM1Xta2USX8QkKRL4imOUSw8xshJsVquOeulplJR7dfEzQUf6$>
>> > >
>> > >     On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx <hjohn at xs4all.nl
>> > >     <mailto:hjohn at xs4all.nl>> wrote:
>> > >
>> > >
>> > >
>> > >         On 02/09/2021 11:57, Nir Lisker wrote:
>> > >         >     So in order
>> > >         >     to make sure that a new interested invalidation listener
>> > >         does not miss
>> > >         >     the fact that a property was *already* invalid, the
>> > >         easiest solution
>> > >         >     might have been to revalidate it upon registration of a
>> > >         new listener
>> > >         >
>> > >         >
>> > >         > But why does an invalidation listener need to know the past
>> > >         state of the
>> > >         > property? It is only interested in the valid -> invalid
>> > >         transition. If
>> > >         > the property was invalid then the listener (in theory)
>> > >         shouldn't receive
>> > >         > any events anyway on subsequent invalidations. (I understand
>> > >         that you
>> > >         > don't justify this, I'm posing it as a general question.)
>> > >
>> > >         Strictly speaking, no, if users are using InvalidationListener
>> > >         correctly
>> > >         then this is definitely correct behavior. I'm not really
>> > >         advocating a
>> > >         change, and I'd even prefer that it be brought in line with the
>> > >         documentation.
>> > >
>> > >         I think however that many users are not using it correctly and
>> > >         expect an
>> > >         invalidation event always the next time the value changes (and
>> > >         their
>> > >         listener will read that value, validating it again), making it
>> > >         act like
>> > >         a light-weight ChangeListener. I know that I probably have
>> > >         written code
>> > >         that made that assumption, and would in the past not even
>> > >         think twice
>> > >         about replacing a change with an invalidation listener or vice
>> > >         versa if
>> > >         that happened to be a better fit. Which is sort of what
>> > >         happened as well
>> > >         in the bidirectional binding PR, and the issue slipped past
>> > >         the author
>> > >         and two reviewers.
>> > >
>> > >         > I suggest that we split the problem into 2: one is the case
>> > >         where the
>> > >         > property was valid when the listener was attached, and the
>> > >         other is when
>> > >         > it was invalid.
>> > >         > * A valid starting state. In this case attaching a listener
>> > >         shouldn't
>> > >         > need to do anything. A subsequent invalidation event will be
>> > >         sent
>> > >         > regardless. Currently, it is calling get() redundantly.
>> > >
>> > >         True, the call to get is redundant in this case. Ugly too,
>> > >         calling get
>> > >         and discarding its result, while the intention is to force the
>> > >         property
>> > >         to become valid.
>> > >
>> > >         > * An invalid starting state. In this case the documentation
>> > >         says that
>> > >         > nothing needs to happen, but get() is called anyway. Here, the
>> > >         > difference is that a subsequent invalidation event is sent
>> > >         in one case
>> > >         > and not in the other. The only way to advance here is to
>> > >         make a design
>> > >         > decision on what should happen, at least that's how I see it.
>> > >
>> > >         The docs are even more specific I think, they say no more
>> > >         events will be
>> > >         generated until it becomes valid -- it doesn't leave any
>> > >         option open
>> > >         that it could generate events if it wanted to.
>> > >
>> > >         > As to the implementation of a possible solution, suppose we
>> > >         add the
>> > >         > isValid method. Upon attaching an invalidation listener, if
>> > >         the property
>> > >         > is valid, we can skip the get() call. That solves the valid
>> > >         starting
>> > >         > state issue. The question is what to do if the property is
>> > >         not valid.
>> > >         >
>> > >         > I also noticed an odd design choice in the implementation of
>> > >         properties:
>> > >         > the value field does not update if the property is bound,
>> > >         instead, the
>> > >         > result of the binding is returned and the value field holds
>> > >         an outdated
>> > >         > value (until the property is unbound).
>> > >
>> > >         Yeah, that might not be a wise decision as that can lead to
>> > >         memory being
>> > >         referenced that users might expect to be freed. I didn't see
>> > >         anywhere
>> > >         defined what will happen to the value of the property when it
>> > >         is unbound
>> > >         again. The current implementation will keep its last value
>> > >         (during the
>> > >         unbind it will take the last value and assign it to its own value
>> > >         field), so the value field should perhaps be nulled out when
>> > >         bound.
>> > >
>> > >         --John
>> > >
>> >

From kcr at openjdk.java.net  Wed Oct 20 13:53:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 Oct 2021 13:53:14 GMT
Subject: Integrated: 8275138: WebView: UserAgent string is empty for first
 request
In-Reply-To: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
References: <LjPdeUMCaVfFqwxGlnLbOkkWFmuQEugd2HX1q7HRvQo=.eaad59a7-1103-4433-872a-9a7d1924c248@github.com>
Message-ID: <Kvyd-pdOz6oxIREKoaYu2J4jQvdmYEwYe4sBw75N6pc=.0bf9dfe9-c2e4-420f-b23d-1d773b928837@github.com>

On Thu, 14 Oct 2021 12:32:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The failure was caused by a change that was done in connection with the WebKit 610.2 update, [JDK-8259635](https://bugs.openjdk.java.net/browse/JDK-8259635). The `FrameLoaderClient::userAgent` function was changed in WebKit itself to be a const method in WebKit 610.2. We override that method in `FrameLoaderClientJava` to return the user agent string, which is done by reading the user agent from an instance of the `Page` class.  `FrameLoaderClientJava` has a `m_page` field that is lazily initialized whenever it is needed. This lazy initialization can no longer be done from the `userAgent` method, since it is `const`, as can be seen from this change that was done as part of WebKit 610.2:
> 
> 
> --- a/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> +++ b/modules/javafx.web/src/main/native/Source/WebKitLegacy/java/WebCoreSupport/FrameLoaderClientJava.cpp
> -String FrameLoaderClientJava::userAgent(const URL&)
> +String FrameLoaderClientJava::userAgent(const URL&) const
>  {
> -    return page()->settings().userAgent();
> +    if (!m_page)
> +        return emptyString();
> +    return m_page->settings().userAgent();
>  }
> 
> 
> Formerly, if the `m_page` field was uninitialized, FrameLoaderClient::userAgent would have initialized it by the call to the `page()` function, but since it is now `const` we can't do that. This means that the user agent string will be empty until some other method is called that initializes the `m_page` field.
> 
> The fix is to initialize that field when the `WebPage` is created. We can't do it in the constructor, since the needed reference to the `Page` class isn't yet available, so I added an `init` method that is called from `WebPage::twkInit`.
> 
> I added a new unit test that fails without the fix and passes with the fix.

This pull request has now been integrated.

Changeset: d6f78e27
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/d6f78e27a698925f029126b8d62a3e88d4d6f868
Stats:     51 lines in 4 files changed: 33 ins; 0 del; 18 mod

8275138: WebView: UserAgent string is empty for first request

Reviewed-by: aghaisas, arapte

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

PR: https://git.openjdk.java.net/jfx/pull/643

From aghaisas at openjdk.java.net  Wed Oct 20 14:48:30 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 20 Oct 2021 14:48:30 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes
Message-ID: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>

This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
Note : 
- The javadoc needs to be generated with the JDK 18 EA build.
- There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

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

Commit messages:
 - 8271091 - fix javadoc warnings

Changes: https://git.openjdk.java.net/jfx/pull/646/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271091
  Stats: 248 lines in 49 files changed: 114 ins; 11 del; 123 mod
  Patch: https://git.openjdk.java.net/jfx/pull/646.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/646/head:pull/646

PR: https://git.openjdk.java.net/jfx/pull/646

From nlisker at openjdk.java.net  Wed Oct 20 15:49:11 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 20 Oct 2021 15:49:11 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <25kwolxFeJq5O3VLwd96nLVFQ0w0KU-ixhTantm5Pfg=.9a8d5bbf-5daf-4000-8464-2346b6f19990@github.com>

On Wed, 20 Oct 2021 14:42:44 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Took a quick look at the new docs. I didn't check the resulting HTML or the corrected of the description, just format and grammar.

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

> 580: 
> 581:     /**
> 582:      * Get the {@code CssMetaData} associated with this class, which may include the

Should be "Gets the..."

Same for the other methods.

modules/javafx.controls/src/main/java/javafx/scene/control/CheckMenuItem.java line 89:

> 87:      **************************************************************************/
> 88:     /**
> 89:      * Constructs a default CheckMenuItem.

`{@code CheckMenuItem}`

modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 874:

> 872: 
> 873:     /**
> 874:      * Get the unmodifiable list of the controls css styleable properties.

Maybe "Gets the unmodifiable list of the control's css styleable properties."? I'm not sure what this method really does, but if it relates to a single control then that apostrophe is needed.

modules/javafx.controls/src/main/java/javafx/scene/control/DateCell.java line 46:

> 44: 
> 45:     /**
> 46:      * Creates a default DateCell.

`{@code DateCell}`

modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 159:

> 157: 
> 158:     /**
> 159:      * Focus the item at the given index.

Focuses

modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 160:

> 158:     /**
> 159:      * Focus the item at the given index.
> 160:      * @param index the index of the item that needs to be focused.

No need for a period at the end.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 1147:

> 1145: 
> 1146:         /**
> 1147:          * Constructs a default CSSBridge

`{@code CSSBridge}`

modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 47:

> 45:     /**
> 46:      * Get the default singleton {@code SortEvent}.
> 47:      * @param <C> type of control

"the type of control"

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableViewSkinBase.java line 252:

> 250: 
> 251:     /**
> 252:      * Constructs a {@code TableViewSkinBase} for given control.

"for the given"

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 731:

> 729: 
> 730:     /**
> 731:      * Handle input method event.

"Handles an input method event"

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualContainerBase.java line 67:

> 65: 
> 66:     /**
> 67:      * Constructs a VirtualContainerBase

`{@code VirtualContainerBase}`

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

PR: https://git.openjdk.java.net/jfx/pull/646

From mstrauss at openjdk.java.net  Wed Oct 20 16:25:03 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 20 Oct 2021 16:25:03 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes
In-Reply-To: <25kwolxFeJq5O3VLwd96nLVFQ0w0KU-ixhTantm5Pfg=.9a8d5bbf-5daf-4000-8464-2346b6f19990@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <25kwolxFeJq5O3VLwd96nLVFQ0w0KU-ixhTantm5Pfg=.9a8d5bbf-5daf-4000-8464-2346b6f19990@github.com>
Message-ID: <Iv39CKSKDBF9rVS52tmbjawHj6z8w_tqJSHrArjNy_A=.65c2608a-6184-490e-88fd-d1ffe200f875@github.com>

On Wed, 20 Oct 2021 15:23:07 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> modules/javafx.controls/src/main/java/javafx/scene/control/Control.java line 874:
> 
>> 872: 
>> 873:     /**
>> 874:      * Get the unmodifiable list of the controls css styleable properties.
> 
> Maybe "Gets the unmodifiable list of the control's css styleable properties."? I'm not sure what this method really does, but if it relates to a single control then that apostrophe is needed.

Also, "CSS" should probably be upper-cased in a sentence, like so: "CSS-styleable"

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

PR: https://git.openjdk.java.net/jfx/pull/646

From prr at openjdk.java.net  Wed Oct 20 16:31:07 2021
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 20 Oct 2021 16:31:07 GMT
Subject: Integrated: 8236689: macOS 10.15 Catalina: LCD text renders badly
In-Reply-To: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
References: <RvalWwDenhZ0x0ELjIl6YMccOtU41MFjuLo-A2CT3e4=.40f5df67-9b91-4850-bd31-30af672a113c@github.com>
Message-ID: <XLDyMtc8VSApQitrxpVAhj13JShMh4vEupAHIJjJm-M=.f4d3a2b1-f04e-4871-8214-9776499ecf23@github.com>

On Wed, 13 Oct 2021 23:59:40 GMT, Phil Race <prr at openjdk.org> wrote:

> On an external (non-retina) monitor JavaFX LCD text on macOS is painful on the eyes.
> Retina diminishes it rather than cures it.
> 
> The problem is a mix of a couple of things
> 1) CoreText no longer generates LCD glyphs (except perhaps if you change some system settings at your own risk)
> 2) Prism's LCD shader assumes it got LCD glyphs and makes sub-pixel positioning adjustments that turn greyscale
> glyphs into multi-coloured glyphs that weren't meant to be ...
> 
> The fix here is to just disable LCD by default on macOS as is already done (eg) on iOS
> This ripples through to make everything use grey scale even if you asked for the LCD (which you can't have)
> It also means if you REALLY want it (and perhaps are tweaking those magical settings) you can have it back
> by just specifying -Dprism.lcdtext=on
> 
> Also it means the pieces of support for this on macos are still there if Apple ever bring it back (unlikely).
> Not that much code would be removed anyway .. a fair amount of it is needed for Windows and Linux.

This pull request has now been integrated.

Changeset: a118d333
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/a118d33314a363336134d31c45b50329594e5a24
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8236689: macOS 10.15 Catalina: LCD text renders badly

Reviewed-by: kcr, pbansal

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

PR: https://git.openjdk.java.net/jfx/pull/642

From mstrauss at openjdk.java.net  Wed Oct 20 17:00:25 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Wed, 20 Oct 2021 17:00:25 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not working
Message-ID: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>

This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.

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

Commit messages:
 - fixed mnemonic parsing
 - failing test

Changes: https://git.openjdk.java.net/jfx/pull/647/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274854
  Stats: 80 lines in 2 files changed: 72 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/647.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/647/head:pull/647

PR: https://git.openjdk.java.net/jfx/pull/647

From arapte at openjdk.java.net  Wed Oct 20 18:13:08 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 20 Oct 2021 18:13:08 GMT
Subject: Integrated: 8274413: FX: Update copyright year in docs,
 readme files to 2022
In-Reply-To: <Xra5wg-Pqq4Z7SxLDD6utrlqDVsckbANzzGi8Kw7O_4=.5167d1bf-d35a-4b4f-9188-1ebd6aec50cf@github.com>
References: <Xra5wg-Pqq4Z7SxLDD6utrlqDVsckbANzzGi8Kw7O_4=.5167d1bf-d35a-4b4f-9188-1ebd6aec50cf@github.com>
Message-ID: <8Jm2ieydKOdIptujLgRFomgwoR3dfwRuPSgkQOafhho=.efae7885-b7c5-448d-b9b4-0578be13a0d3@github.com>

On Wed, 20 Oct 2021 11:53:30 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Copyright year in these 3 docs needs to be updated to 2022.

This pull request has now been integrated.

Changeset: 7be0abb9
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/7be0abb9aa5e86e953b13d4ad1d88000e652029c
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8274413: FX: Update copyright year in docs, readme files to 2022

Reviewed-by: kcr

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

PR: https://git.openjdk.java.net/jfx/pull/645

From arapte at openjdk.java.net  Wed Oct 20 18:57:19 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 20 Oct 2021 18:57:19 GMT
Subject: RFR: 8272638: Update copyright header for files modified in 2021
Message-ID: <lARSYYEFWsxqVmCBDxuEej6bx7P-0jTGR0tbHn7icgA=.5bf63095-2fe7-4ea9-bf83-db201c62ab8d@github.com>

Change to update copyright year of files modified in 2021.

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

Commit messages:
 - copyright-update

Changes: https://git.openjdk.java.net/jfx/pull/648/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=648&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272638
  Stats: 42 lines in 42 files changed: 0 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jfx/pull/648.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/648/head:pull/648

PR: https://git.openjdk.java.net/jfx/pull/648

From michaelstrau2 at gmail.com  Wed Oct 20 19:07:07 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Wed, 20 Oct 2021 21:07:07 +0200
Subject: Easier handling of ObservableList/Set/Map change events
Message-ID: <CAJEpuXQW_TLdbOmes-L0LC_yy=gfQs3LHAMzWiWt6mS7ff37aw@mail.gmail.com>

I'd like to gauge interest on a small feature addition for JavaFX collections.

ObservableList (and similarly, ObservableSet/ObservableMap) allows
developers to register ListChangeListeners to observe changes to the
list. In some cases, these changes are applied to another list or
projected into a different form.

Implementing ListChangeListener correctly is quite tricky, especially
if the ObservableList implementation also fires "replace" and
"permutate" events. As a result, it is very easy to implement this
interface wrongly, which often goes undetected when the implementation
is only tested against basic operations like "add" and "remove".

Maybe we could make it easier for developers to get it right more of
the time, by offering pre-built adapters for ListChangeListener,
SetChangeListener and MapChangeListener.

Here's what that could look like:

    public abstract class ListChangeListenerAdapter<E> implements
ListChangeListener<E> {
        // Basic methods
        public abstract void onAdded(int index, E element);
        public abstract void onRemoved(int index);

        // Optional methods
        public void onAdded(int index, List<? extends E> elements);
        public void onRemoved(int from, int to);
        public void onReplaced(int index, E element);
        public void onUpdated(int index, E element);
    }

An implementation of this adapter must at the very least implement the
basic `onAdded` and `onRemoved` methods. The adapter will then
correctly map all other change events ("replace" and "permutate") to
these methods. All adapter methods will always be called in exactly
the right order, such that they always refer to the current state of
the list.

An adapter implementation can improve performance characteristics by
overriding the optional `onAdded`, `onRemoved` and `onReplaced`
methods (which map to `addAll`, `remove` and `set` of the List
interface). Optional methods are implemented by default to throw a
private exception in ListChangeListenerAdapter, which is used to
discover whether the methods are overridden and should be called
instead of the basic methods.

From kcr at openjdk.java.net  Wed Oct 20 22:35:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 Oct 2021 22:35:09 GMT
Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5]
In-Reply-To: <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
References: <rucQpoQckz65kU-gd1XWyNifMwzjSTOz197mwwEKTFQ=.189d92da-7491-42e0-8934-8a62904d6828@github.com>
 <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
Message-ID: <bNp23YXMjWqr3UmYPDl4EpsjWB4Ag0wQa0BN_TLqo9M=.9825d44c-cb16-4df4-8291-01738bf17b1d@github.com>

On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work.  Also added a single JUnit 5 tests, and confirmed it works.
>> 
>> I've updated the Eclipse project file for the base module only.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd junit declaration in allprojects and set junit version to 4.13.2

As indicated in the JBS issue, we can now proceed with this. You will need to change the title of this PR to match the updated bug title.

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

PR: https://git.openjdk.java.net/jfx/pull/633

From kcr at openjdk.java.net  Wed Oct 20 22:40:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 20 Oct 2021 22:40:08 GMT
Subject: RFR: 8272638: Update copyright header for files modified in 2021
In-Reply-To: <lARSYYEFWsxqVmCBDxuEej6bx7P-0jTGR0tbHn7icgA=.5bf63095-2fe7-4ea9-bf83-db201c62ab8d@github.com>
References: <lARSYYEFWsxqVmCBDxuEej6bx7P-0jTGR0tbHn7icgA=.5bf63095-2fe7-4ea9-bf83-db201c62ab8d@github.com>
Message-ID: <i3n0DgoUWCy5PXx7i5qcenHD-ObGgbhTESIOTDkstC4=.bcd7cafa-2876-4b62-844f-a2bb991733a2@github.com>

On Wed, 20 Oct 2021 18:51:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Change to update copyright year of files modified in 2021.

Looks good.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/648

From arapte at openjdk.java.net  Thu Oct 21 07:31:07 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Thu, 21 Oct 2021 07:31:07 GMT
Subject: Integrated: 8272638: Update copyright header for files modified in
 2021
In-Reply-To: <lARSYYEFWsxqVmCBDxuEej6bx7P-0jTGR0tbHn7icgA=.5bf63095-2fe7-4ea9-bf83-db201c62ab8d@github.com>
References: <lARSYYEFWsxqVmCBDxuEej6bx7P-0jTGR0tbHn7icgA=.5bf63095-2fe7-4ea9-bf83-db201c62ab8d@github.com>
Message-ID: <JfeWPP-CvVfdssPPS8tSW90itDmQgmZiqUCYyW1b160=.6fd43dcb-8bce-4330-b2b6-87efebd7d8d6@github.com>

On Wed, 20 Oct 2021 18:51:21 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

> Change to update copyright year of files modified in 2021.

This pull request has now been integrated.

Changeset: 28e86841
Author:    Ambarish Rapte <arapte at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/28e86841412dce99b92b8d75b798a63312aa25cd
Stats:     42 lines in 42 files changed: 0 ins; 0 del; 42 mod

8272638: Update copyright header for files modified in 2021

Reviewed-by: kcr

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

PR: https://git.openjdk.java.net/jfx/pull/648

From aghaisas at openjdk.java.net  Thu Oct 21 08:58:37 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 21 Oct 2021 08:58:37 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v2]
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <K2OHVEuIGcoKhjvc6vHFiktwExS2OlUYJyucRDS9nbA=.a42e35a3-36b1-4cd6-abd9-66641f232d75@github.com>

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  javadoc minor corrections

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/646/files
  - new: https://git.openjdk.java.net/jfx/pull/646/files/6f802004..38563835

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=00-01

  Stats: 55 lines in 47 files changed: 0 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jfx/pull/646.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/646/head:pull/646

PR: https://git.openjdk.java.net/jfx/pull/646

From mhanl at openjdk.java.net  Thu Oct 21 18:54:13 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Thu, 21 Oct 2021 18:54:13 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>
Message-ID: <XR9i1VFvlQIG2Ny7Km71Qz2OIva3955jMf7MZDqKB7w=.d8518c74-c0bf-48eb-b988-fbdae2c539c3@github.com>

On Fri, 15 Oct 2021 10:21:12 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
>> 
>> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
>> 
>> Added/unignored cell tests that are failing/passing before/after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed formatting as suggested in review
>   
>   and removed unused (by this fix) import in same file

modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 548:

> 546:         int editingRow = 1;
> 547:         cell.updateIndex(editingRow);
> 548:         TablePosition<?,?> editingCell = new TablePosition<>(table, editingRow, editingColumn);

Just saw you added the space for the `<?,?>` in line 559 (which I didn't saw ??) but not here :)

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

PR: https://git.openjdk.java.net/jfx/pull/638

From almatvee at openjdk.java.net  Thu Oct 21 21:49:17 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 21 Oct 2021 21:49:17 GMT
Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media
Message-ID: <Enwa8GgQrbTCYuK9X3GgRtr8vm9hqSMCssqPHVFupRc=.c5acbbb3-1499-4df1-a0b9-554ed554585e@github.com>

- Added support for H.265/HEVC for all 3 platforms.
 - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported.
 - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC.
 - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering.
 - Resolution upto 4k is supported.

Additional runtime dependency requirements:
Windows: Windows 10 with HEVC Video Extensions installed.
macOS: macOS High Sierra and later
Linux: at least libavcodec56 and libswscale5

Additional build dependency:
Linux: libswscale-dev

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

Commit messages:
 - 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
 - JDK-8273096: Add support for H.265/HEVC to JavaFX Media

Changes: https://git.openjdk.java.net/jfx/pull/649/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273096
  Stats: 2039 lines in 30 files changed: 1916 ins; 28 del; 95 mod
  Patch: https://git.openjdk.java.net/jfx/pull/649.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649

PR: https://git.openjdk.java.net/jfx/pull/649

From sproket at videotron.ca  Fri Oct 22 01:30:29 2021
From: sproket at videotron.ca (Dan Howard)
Date: Thu, 21 Oct 2021 21:30:29 -0400
Subject: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media
In-Reply-To: <Enwa8GgQrbTCYuK9X3GgRtr8vm9hqSMCssqPHVFupRc=.c5acbbb3-1499-4df1-a0b9-554ed554585e@github.com>
References: <Enwa8GgQrbTCYuK9X3GgRtr8vm9hqSMCssqPHVFupRc=.c5acbbb3-1499-4df1-a0b9-554ed554585e@github.com>
Message-ID: <7b43a144-f2bb-537a-bed8-9ea64c294961@videotron.ca>

Very cool.

On 10/21/2021 5:49 PM, Alexander Matveev wrote:
> - Added support for H.265/HEVC for all 3 platforms.
>   - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported.
>   - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC.
>   - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering.
>   - Resolution upto 4k is supported.
>
> Additional runtime dependency requirements:
> Windows: Windows 10 with HEVC Video Extensions installed.
> macOS: macOS High Sierra and later
> Linux: at least libavcodec56 and libswscale5
>
> Additional build dependency:
> Linux: libswscale-dev
>
> -------------
>
> Commit messages:
>   - 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
>   - JDK-8273096: Add support for H.265/HEVC to JavaFX Media
>
> Changes: https://git.openjdk.java.net/jfx/pull/649/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=649&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8273096
>    Stats: 2039 lines in 30 files changed: 1916 ins; 28 del; 95 mod
>    Patch: https://git.openjdk.java.net/jfx/pull/649.diff
>    Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649
>
> PR: https://git.openjdk.java.net/jfx/pull/649

From fastegal at openjdk.java.net  Fri Oct 22 09:48:06 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 22 Oct 2021 09:48:06 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <XR9i1VFvlQIG2Ny7Km71Qz2OIva3955jMf7MZDqKB7w=.d8518c74-c0bf-48eb-b988-fbdae2c539c3@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>
 <XR9i1VFvlQIG2Ny7Km71Qz2OIva3955jMf7MZDqKB7w=.d8518c74-c0bf-48eb-b988-fbdae2c539c3@github.com>
Message-ID: <sldN5QLy1wuxhbzhCg6g2TxZkLfBM3f-GQrbe-tgqiQ=.c2073e40-bda3-464e-861f-57a4b90a1a82@github.com>

On Thu, 21 Oct 2021 18:50:45 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed formatting as suggested in review
>>   
>>   and removed unused (by this fix) import in same file
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 548:
> 
>> 546:         int editingRow = 1;
>> 547:         cell.updateIndex(editingRow);
>> 548:         TablePosition<?,?> editingCell = new TablePosition<>(table, editingRow, editingColumn);
> 
> Just saw you added the space for the `<?,?>` in line 559 (which I didn't saw ??) but not here :)

darn .. ;) Thanks

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

PR: https://git.openjdk.java.net/jfx/pull/638

From fastegal at openjdk.java.net  Fri Oct 22 10:19:05 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 22 Oct 2021 10:19:05 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <sldN5QLy1wuxhbzhCg6g2TxZkLfBM3f-GQrbe-tgqiQ=.c2073e40-bda3-464e-861f-57a4b90a1a82@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>
 <XR9i1VFvlQIG2Ny7Km71Qz2OIva3955jMf7MZDqKB7w=.d8518c74-c0bf-48eb-b988-fbdae2c539c3@github.com>
 <sldN5QLy1wuxhbzhCg6g2TxZkLfBM3f-GQrbe-tgqiQ=.c2073e40-bda3-464e-861f-57a4b90a1a82@github.com>
Message-ID: <KnvnZsnvgQ159mYjG7dJaiaKTfBgrKfOLaqIE3ZlvHM=.bdb96427-c209-4683-ad3f-e4e12903cb9a@github.com>

On Fri, 22 Oct 2021 09:45:10 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java line 548:
>> 
>>> 546:         int editingRow = 1;
>>> 547:         cell.updateIndex(editingRow);
>>> 548:         TablePosition<?,?> editingCell = new TablePosition<>(table, editingRow, editingColumn);
>> 
>> Just saw you added the space for the `<?,?>` in line 559 (which I didn't saw ??) but not here :)
>
> darn .. ;) Thanks

hmm .. I'm all for consistency, so don't mind trying again but ... what _is_ the formatting rule? Searching  in controls:

- wildcard search: `<?,?>`  = 1000+ vs. `<?, ?>`  = 379
- verbatim:  `<?,?>` = 173 vs. `<?, ?>` = 98 

Looks .. inconclusive .. ???

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

PR: https://git.openjdk.java.net/jfx/pull/638

From fastegal at openjdk.java.net  Fri Oct 22 10:36:24 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 22 Oct 2021 10:36:24 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v3]
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <6Yizd_tITIxMk8FQyqNQEsLQButJKy3MTQGro0ax1N4=.ec406d6e-05fc-4d00-86a0-0c01db1e9d6e@github.com>

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  next try with fixing the formatting

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/638/files
  - new: https://git.openjdk.java.net/jfx/pull/638/files/4f76e1fe..4fd55ffa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=01-02

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

PR: https://git.openjdk.java.net/jfx/pull/638

From mhanl at openjdk.java.net  Fri Oct 22 10:36:24 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 22 Oct 2021 10:36:24 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v2]
In-Reply-To: <KnvnZsnvgQ159mYjG7dJaiaKTfBgrKfOLaqIE3ZlvHM=.bdb96427-c209-4683-ad3f-e4e12903cb9a@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <-AnY4FlQUKuRHqigF_SR74qtlwUDqtz6DGPXXYnkUyw=.d6f62572-965c-4905-a56c-b201eb69da1f@github.com>
 <XR9i1VFvlQIG2Ny7Km71Qz2OIva3955jMf7MZDqKB7w=.d8518c74-c0bf-48eb-b988-fbdae2c539c3@github.com>
 <sldN5QLy1wuxhbzhCg6g2TxZkLfBM3f-GQrbe-tgqiQ=.c2073e40-bda3-464e-861f-57a4b90a1a82@github.com>
 <KnvnZsnvgQ159mYjG7dJaiaKTfBgrKfOLaqIE3ZlvHM=.bdb96427-c209-4683-ad3f-e4e12903cb9a@github.com>
Message-ID: <C5wR8c5ZkeTvSrPewtzYPk7FgkW50pZpUAVGZEf75ZU=.a2216c64-bda3-4ede-81aa-464955483629@github.com>

On Fri, 22 Oct 2021 10:15:59 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> darn .. ;) Thanks
>
> hmm .. I'm all for consistency, so don't mind trying again but ... what _is_ the formatting rule? Searching  in controls:
> 
> - wildcard search: `<?,?>`  = 1000+ vs. `<?, ?>`  = 379
> - verbatim:  `<?,?>` = 173 vs. `<?, ?>` = 98 
> 
> Looks .. inconclusive .. ???
> 
> But then, [generics tutorial](https://docs.oracle.com/javase/tutorial/java/generics/types.html) has the space - so the space it will be.

Weird. Also standard classes like HashMap, AbstractMap or just Map doesn't have the space. I'm also for consisteny, but don't know which would be 'the best' ??

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

PR: https://git.openjdk.java.net/jfx/pull/638

From aghaisas at openjdk.java.net  Fri Oct 22 11:38:24 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 22 Oct 2021 11:38:24 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes
Message-ID: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>

This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.

Note :
- The javadoc needs to be generated with the JDK 18 EA build.
- There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

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

Commit messages:
 - 8271090 - fix javadoc warnings - base,media,fxml
 - 8271090 - fix javadoc warnings

Changes: https://git.openjdk.java.net/jfx/pull/650/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271090
  Stats: 107 lines in 29 files changed: 74 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jfx/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/650/head:pull/650

PR: https://git.openjdk.java.net/jfx/pull/650

From kcr at openjdk.java.net  Fri Oct 22 14:44:12 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 14:44:12 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v2]
In-Reply-To: <K2OHVEuIGcoKhjvc6vHFiktwExS2OlUYJyucRDS9nbA=.a42e35a3-36b1-4cd6-abd9-66641f232d75@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <K2OHVEuIGcoKhjvc6vHFiktwExS2OlUYJyucRDS9nbA=.a42e35a3-36b1-4cd6-abd9-66641f232d75@github.com>
Message-ID: <DZzouNNxlcXiPexOELDU4oPiGiRPpan2nGH8ejqM-tI=.a2e35392-7c89-4b38-bb2e-d5a9d9e75f8c@github.com>

On Thu, 21 Oct 2021 08:58:37 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc minor corrections

See comments below.

modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 470:

> 468:      * {@code CssMetaData} of its superclasses.
> 469:      * @return the {@code CssMetaData}
> 470:      * @since JavaFX 8.0

The class already has an `@since JavaFX 8.0` tag so this is unnecessary. It's also unrelated to this fix (and we would need a CSR for any changes to `@since` tags).

modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 160:

> 158:     /**
> 159:      * Focuses the item at the given index.
> 160:      * @param index the index of the item that needs to be focused

Minor: I recommend removing "that needs" from this `@param`.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 201:

> 199:      * this specific {@code PopupControl}.
> 200:      * @return the {@code StringProperty} representing the CSS style
> 201:      */

I recommend taking the information from the setter and copying it here. The docs can/should then be removed from both the setter and the getter. The first sentence should describe the property so does not need to start with "Gets the ...". You can add the information about `null` being turned into the empty string as a sentence in the Description. The `@defaultValue empty string` means that the information in the `@return` of the getter is unnecessary.

modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 47:

> 45:     /**
> 46:      * Gets the default singleton {@code SortEvent}.
> 47:      * @param <C> the type of control

Can you also add this `@param` tag to the class description? I'm a little surprised that javadoc doesn't flag it as missing.

modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 59:

> 57:     /**
> 58:      * Constructs a new {@code Event} with the specified event source, target
> 59:      * and type. If the source or target is set to {@code null}, it is replaced

That should be "a new `{@code SortEvent}` ...". Also, since there is no type parameter, you should remove "and type" (and replace the comma after source with "and").

modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 63:

> 61:      *
> 62:      * @param source the event source which sent the event
> 63:      * @param target the target of the scroll to operation

That should be "the target of the event".

modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 405:

> 403:     }
> 404: 
> 405:     public final DoubleProperty tabMaxWidthProperty() {

The best practice for properties is to put the description on exactly one of the `xxx` private field or the `xxxProperty` method, and not on the setter or getter (unless there is a specific need to document something special in the setter or getter). There is a separate JBS issue, [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085), tracking the fix for the `maxWidth` and `maxHeight` properties.

You can either revert this change, in which case we'll need a new PR for that issue (it can be done later), or else modify this change to match the best practice as noted in JDK-8271085 and add that issue to this PR. The latter will require addressing the other methods in this file as noted in that JBS bug.

modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 501:

> 499:     }
> 500: 
> 501:     public final DoubleProperty tabMaxHeightProperty() {

Same comment as above. This needs to be reverted or modified.

modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableColumn.java line 625:

> 623:      * Gets the {@code CssMetaData} associated with this class, which may include the
> 624:      * {@code CssMetaData} of its superclasses.
> 625:      * @return empty list is returned as of now

Minor: I recommend adding a second sentence to the Description to the effect that it is currently an empty list, and then have the return tag be simply `@return an empty list`

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 118:

> 116:     /** Line unit */      LINE,
> 117:     /** Paragraph unit */ PARAGRAPH,
> 118:     /** Page unit */      PAGE };

I would prefer that the javadoc tag and the enum be on separate lines.


    /** Character unit */
    CHARACTER,
    /** Word unit */
    WORD,
    ...

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 602:

> 600: 
> 601:     /**
> 602:      * Get the path elements describing the shape of the underline for the given range.

Gets

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java line 609:

> 607:     protected abstract PathElement[] getUnderlineShape(int start, int end);
> 608: 
> 609:     /** Get the path elements describing the bounding rectangles for the given range of text.

Gets

modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java line 1168:

> 1166:      */
> 1167:     public enum Command {
> 1168:         /** Cut command.*/    CUT("cut"),

Same comment as in `TextInputControlSkin`.

modules/javafx.web/src/main/java/javafx/scene/web/HTMLEditorSkin.java line 1212:

> 1210: 
> 1211:         /**
> 1212:          * Get the name of this command.

Gets

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

PR: https://git.openjdk.java.net/jfx/pull/646

From nlisker at openjdk.java.net  Fri Oct 22 14:57:08 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 22 Oct 2021 14:57:08 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>

On Fri, 22 Oct 2021 11:23:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

modules/javafx.graphics/src/main/java/javafx/scene/Camera.java line 164:

> 162:     /**
> 163:      * Creates a {@code Camera}.
> 164:      */

Sine the constructor is a `protected` for an `abstract` class, it doesn't create a `Camera` in the normal sense of constructors. I would write something like "Shared constructor for subclasses of `Camera`".

modules/javafx.graphics/src/main/java/javafx/scene/paint/Material.java line 81:

> 79:     /**
> 80:      * Creates a {@code Material}.
> 81:      */

Same comment as in `Camera`.

modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 91:

> 89:      * Default size of the {@code Box}.
> 90:      */
> 91:     public static final double DEFAULT_SIZE = 2;

This field was exposed by mistake probably. The other shapes don't expose theirs. I recommend to deprecate for removal.

modules/javafx.graphics/src/main/java/javafx/scene/shape/Shape3D.java line 102:

> 100:     /**
> 101:      * Creates a {@code Shape3D}.
> 102:      */

Same comment as in `Camera`,

modules/javafx.media/src/main/java/javafx/scene/media/Track.java line 85:

> 83:     /**
> 84:      * Gets the <code>Map</code> containing all known metadata for this <code>Track</code>.
> 85:      * @return the <code>Map</code> containing all known metadata for this <code>Track</code>

We tend to use `{@code }` over `<code> </code>`, but I don't think it matter.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From duke at openjdk.java.net  Fri Oct 22 15:01:38 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 22 Oct 2021 15:01:38 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v5]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <SPY9zh2COe6Ek0cQCBp8Up1jCAEMyxP1M75hB7Njp4E=.da491eee-0ca2-4c65-82b0-e5d60014a8d6@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  JUnit Test class for verifying JDK-8255015 added.

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/c7e58901..a3677124

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=03-04

  Stats: 180 lines in 1 file changed: 180 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From kcr at openjdk.java.net  Fri Oct 22 15:17:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 15:17:07 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <kg8M8SFPcipygXlU5n5XbzZLhse99ngPlC4eYOk3u30=.687cb64a-1b7c-420e-ad61-4b054545a1fe@github.com>

On Fri, 22 Oct 2021 11:23:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

I left two comments below.

modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1307:

> 1305:      * @return the full screen exit hint property
> 1306:      * @since JavaFX 8.0
> 1307:      */

Instead of this change, I recommend moving the docs that are currently on the getter to the private `fullScreenExitHint` field. As mentioned in the review for PR #646 the best practice is that exactly one of the private field or the property method should have docs, and that the getter and setter should have no docs (absent a compelling reason).

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 781:

> 779:      * Sets the {@code Scene} of this {@code Window}.
> 780:      * @param value the {@code Scene} to be set
> 781:      */

The javadoc tool automatically generates docs for this setter (you can see this from the generated docs without this change), including the property description, so this change will actually lose information. I'm guessing that the tool warns on this method because the setter is protected (rather than public). So we should probably file a bug against the javadoc tool. As for how to fix it, you can either suppress the warning (I'm not sure whether that's possible), or you can copy the information from the property method with a leading sentence that matches what javadoc _would_ generate.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From kcr at openjdk.java.net  Fri Oct 22 15:30:10 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 15:30:10 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes
In-Reply-To: <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
Message-ID: <CnLkSrAOTu7zIDPjRha60ugvGA3ECqYvlthScGE73Js=.d027c43a-22e0-4c81-ad0f-bb680985cfcd@github.com>

On Fri, 22 Oct 2021 14:48:31 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> modules/javafx.graphics/src/main/java/javafx/scene/Camera.java line 164:
> 
>> 162:     /**
>> 163:      * Creates a {@code Camera}.
>> 164:      */
> 
> Sine the constructor is a `protected` for an `abstract` class, it doesn't create a `Camera` in the normal sense of constructors. I would write something like "Shared constructor for subclasses of `Camera`".

Good catch. We've started using "Constructor for subclasses to call." as the description of such classes. See PR #283 for example.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From duke at openjdk.java.net  Fri Oct 22 15:32:30 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 22 Oct 2021 15:32:30 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v6]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <ndD_dDYiwbe4EuRPYNVW3D1lFH5CJrJaE54CSydy-9o=.18ce3f80-88cf-4815-9edf-3b8fcd82f9be@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8255015: JUnit Test class added.

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/a3677124..3e1af1c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=04-05

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From kcr at openjdk.java.net  Fri Oct 22 15:33:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 15:33:13 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes
In-Reply-To: <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
Message-ID: <juiJw5tGESVbOQ1Rt_iEzA-MkLA372ZncTxnEBmtJwU=.322ec4de-a945-4778-94ae-a25c8c8d6e05@github.com>

On Fri, 22 Oct 2021 14:35:23 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 91:
> 
>> 89:      * Default size of the {@code Box}.
>> 90:      */
>> 91:     public static final double DEFAULT_SIZE = 2;
> 
> This field was exposed by mistake probably. The other shapes don't expose theirs. I recommend to deprecate for removal.

Agreed. That would need to be done in a follow-up issue, and with a CSR. So just revert this addition for this PR.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From duke at openjdk.java.net  Fri Oct 22 15:37:38 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 22 Oct 2021 15:37:38 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v7]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <RxdyipHKtUcaXP_EaQXOlhrCzDwmrqHiuTbGhYabPMQ=.8114acd6-18d2-4f7d-934a-f113d9b59849@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'openjdk:master' into fix-8255015
 - 8255015: JUnit Test class added.
 - Merge branch 'openjdk:master' into fix-8255015
 - Merge branch 'openjdk:master' into fix-8255015
 - Merge branch 'openjdk:master' into fix-8255015
 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/3e1af1c3..4168f5f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=05-06

  Stats: 4396 lines in 237 files changed: 3132 ins; 530 del; 734 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Fri Oct 22 16:15:34 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 22 Oct 2021 16:15:34 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v8]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <JVZFhfdE_ui9809kyUOqCkFK3IultBkZQlmhqn0aYNM=.1bc84a7d-d8aa-417c-92fe-333546712ef5@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  8255015: Tabs removed from PointLightIllumination.java

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/4168f5f3..b0b6c13b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=06-07

  Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Fri Oct 22 17:37:20 2021
From: duke at openjdk.java.net (Martin Fox)
Date: Fri, 22 Oct 2021 17:37:20 GMT
Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on
 macOS
Message-ID: <OfW1k_dpiMjg9jY3o_xiL235DXzrS1Fn6_0WWVeBAF4=.88fe83b6-a2be-4ef3-9ff4-466651562a1a@github.com>

During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing.

This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been.

For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms.

As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation.  There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level.

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

Commit messages:
 - 8227371 Drag&Drop while holding the CMD key does not work on macOS

Changes: https://git.openjdk.java.net/jfx/pull/651/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=651&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8227371
  Stats: 87 lines in 3 files changed: 78 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jfx/pull/651.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/651/head:pull/651

PR: https://git.openjdk.java.net/jfx/pull/651

From kcr at openjdk.java.net  Fri Oct 22 18:00:25 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 18:00:25 GMT
Subject: RFR: 8275815: OCA link in README.md and CONTRIBUTING.md is broken
Message-ID: <BhAEPccJgAHJeeAPw63PsTQw586RsnmMy1ky3fOIlXE=.63bfd225-9a11-4319-a0a4-335c0e2e13d9@github.com>

The PR fixes the broken links as described in the JBS issue. The correct link for the Oracle Contributor Agreement (OCA) is:

https://oca.opensource.oracle.com/

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

Commit messages:
 - 8275815: OCA link in README.md and CONTRIBUTING.md is broken

Changes: https://git.openjdk.java.net/jfx/pull/652/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=652&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275815
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/652.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/652/head:pull/652

PR: https://git.openjdk.java.net/jfx/pull/652

From duke at openjdk.java.net  Fri Oct 22 18:05:40 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 22 Oct 2021 18:05:40 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v9]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <SS6tOLsHFKnga5GxcVYua6ZT1PvWgiNT72XJVZYdz6Y=.612a8805-00e8-4329-a552-a19e6c61356a@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  8255015: Comment about copying pixel scale factors corrected

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/b0b6c13b..280ae78c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From nlisker at openjdk.java.net  Fri Oct 22 19:44:08 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 22 Oct 2021 19:44:08 GMT
Subject: RFR: 8275815: OCA link in README.md and CONTRIBUTING.md is broken
In-Reply-To: <BhAEPccJgAHJeeAPw63PsTQw586RsnmMy1ky3fOIlXE=.63bfd225-9a11-4319-a0a4-335c0e2e13d9@github.com>
References: <BhAEPccJgAHJeeAPw63PsTQw586RsnmMy1ky3fOIlXE=.63bfd225-9a11-4319-a0a4-335c0e2e13d9@github.com>
Message-ID: <SxMxI9kKCbl_74cermhuvmdAxx5jhr1q78Jx1ftdYJU=.b31aa5cd-2c65-4b75-9111-587ade6c000d@github.com>

On Fri, 22 Oct 2021 17:53:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The PR fixes the broken links as described in the JBS issue. The correct link for the Oracle Contributor Agreement (OCA) is:
> 
> https://oca.opensource.oracle.com/

Marked as reviewed by nlisker (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/652

From kcr at openjdk.java.net  Fri Oct 22 20:19:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 20:19:08 GMT
Subject: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5]
In-Reply-To: <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
References: <rucQpoQckz65kU-gd1XWyNifMwzjSTOz197mwwEKTFQ=.189d92da-7491-42e0-8934-8a62904d6828@github.com>
 <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
Message-ID: <ijgzs8m6mYOY-ZJA7PyV1VKB_DhZGgibf4XmiJDxPDk=.1072dc5b-914a-4e8f-ae4b-5bb5add31fdf@github.com>

On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work.  Also added a single JUnit 5 tests, and confirmed it works.
>> 
>> I've updated the Eclipse project file for the base module only.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd junit declaration in allprojects and set junit version to 4.13.2

It looks like I spoke too soon. I am informed there is still another needed step.

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

PR: https://git.openjdk.java.net/jfx/pull/633

From kcr at openjdk.java.net  Fri Oct 22 20:21:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 22 Oct 2021 20:21:09 GMT
Subject: Integrated: 8275815: OCA link in README.md and CONTRIBUTING.md is
 broken
In-Reply-To: <BhAEPccJgAHJeeAPw63PsTQw586RsnmMy1ky3fOIlXE=.63bfd225-9a11-4319-a0a4-335c0e2e13d9@github.com>
References: <BhAEPccJgAHJeeAPw63PsTQw586RsnmMy1ky3fOIlXE=.63bfd225-9a11-4319-a0a4-335c0e2e13d9@github.com>
Message-ID: <D37DnfnmmcdcB14CBGQhluQ7UkKQWHfbAH_nT4N4G2g=.7f5574de-085e-4759-8a35-35385760da73@github.com>

On Fri, 22 Oct 2021 17:53:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> The PR fixes the broken links as described in the JBS issue. The correct link for the Oracle Contributor Agreement (OCA) is:
> 
> https://oca.opensource.oracle.com/

This pull request has now been integrated.

Changeset: d244b305
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/d244b3054aa3a735825c360159826bc414df36ca
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8275815: OCA link in README.md and CONTRIBUTING.md is broken

Reviewed-by: nlisker

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

PR: https://git.openjdk.java.net/jfx/pull/652

From duke at openjdk.java.net  Sat Oct 23 18:23:02 2021
From: duke at openjdk.java.net (Martin Fox)
Date: Sat, 23 Oct 2021 18:23:02 GMT
Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on
 macOS
In-Reply-To: <OfW1k_dpiMjg9jY3o_xiL235DXzrS1Fn6_0WWVeBAF4=.88fe83b6-a2be-4ef3-9ff4-466651562a1a@github.com>
References: <OfW1k_dpiMjg9jY3o_xiL235DXzrS1Fn6_0WWVeBAF4=.88fe83b6-a2be-4ef3-9ff4-466651562a1a@github.com>
Message-ID: <gcbIgT3I-Mubs6ms4EtGeuto1R1pE7CGd2k3Gq0yXP8=.837923d6-3e94-45fb-855e-8cc8c0e48ec4@github.com>

On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox <duke at openjdk.java.net> wrote:

> During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing.
> 
> This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been.
> 
> For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms.
> 
> As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation.  There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level.

No, my changes won?t fix JDK-8264172. Anything that changes the way JavaFX interacts with external applications like Finder has to go through the Java CSR review process and I wanted to avoid that. I did look into this bug and determined there?s nothing much we can fix.

When it comes to using the Command key to select Move I discovered that Finder doesn?t respond to Move from another app anyway. Drags from the Finder complete successfully on the drop end but the Finder just ignores the Move. I?m pretty sure this is by design since it conforms with the Apple user interface guidelines.

You have to use the Control modifier key to select Link when dragging files from the Finder to a JavaFX app. There?s nothing we can do about that, modifier key filtering between applications is handled by the OS and it uses obsolete conventions carried over from NeXTSTEP. And unfortunately given the weird way the OS filters the modifier keys there?s no good work-around.

By the way, Apple?s online API documentation (in NSDraggingInfo draggingSourceOperationMask) isn?t accurate, it seems to be describing how Finder works internally. There are older documents which describe the OS behavior correctly. I?ve entered a bug against the online docs which I?m sure Apple will ignore.

Let me know if you want further details on any of this.

> On Oct 23, 2021, at 3:56 AM, Christoph ***@***.***> wrote:
> 
> 
> Thanks for tackling this issue, much appreciated. I reported a similar one a while ago https://bugs.openjdk.java.net/browse/JDK-8264172 <https://bugs.openjdk.java.net/browse/JDK-8264172> Can you confirm this will also be fixed if you drag a file?
> 
> ?
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jfx/pull/651#issuecomment-950134569>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC4G54BWPBFUQKE33NCT323UIKIFHANCNFSM5GRBIDPA>.
> Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. 
>

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

PR: https://git.openjdk.java.net/jfx/pull/651

From duke at openjdk.java.net  Sat Oct 23 18:28:05 2021
From: duke at openjdk.java.net (Christoph)
Date: Sat, 23 Oct 2021 18:28:05 GMT
Subject: RFR: 8227371: Drag&Drop while holding the CMD key does not work on
 macOS
In-Reply-To: <OfW1k_dpiMjg9jY3o_xiL235DXzrS1Fn6_0WWVeBAF4=.88fe83b6-a2be-4ef3-9ff4-466651562a1a@github.com>
References: <OfW1k_dpiMjg9jY3o_xiL235DXzrS1Fn6_0WWVeBAF4=.88fe83b6-a2be-4ef3-9ff4-466651562a1a@github.com>
Message-ID: <S_BGjll899XEQ5HDesaZ0ynYazUjJd6M9n45K2mRQ18=.33731297-8808-434c-b1f2-c8e336901a7f@github.com>

On Fri, 22 Oct 2021 17:32:10 GMT, Martin Fox <duke at openjdk.java.net> wrote:

> During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing.
> 
> This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been.
> 
> For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms.
> 
> As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation.  There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level.

Thanks for tackling this issue, much appreciated. I reported a similar one a while ago https://bugs.openjdk.java.net/browse/JDK-8264172  Can you confirm this will also be fixed if you drag a file?

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

PR: https://git.openjdk.java.net/jfx/pull/651

From duke at openjdk.java.net  Sun Oct 24 15:20:36 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Sun, 24 Oct 2021 15:20:36 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v10]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <6Els5JgYdAxhjz2Ppfpe_xAQHRXZNlndjMq8N5wHSOU=.54ceae90-807c-46ca-8784-362b5dc3ee48@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  8255015: Comments corrected

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/280ae78c..cc995300

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=08-09

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

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Sun Oct 24 16:08:02 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Sun, 24 Oct 2021 16:08:02 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
In-Reply-To: <D9L0443-Xbl9JPqlmCDhUBZQN-bs20L_XOq0PWtHWF4=.af7ced3c-31b9-46f7-95b6-38c4486d8035@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <nzw9tOphCjxhIQ265m-UE5bIleCrQ8saJfuCDKy_15w=.bce2d7d6-3696-4c76-b09d-2aca4ad86c66@github.com>
 <awjsHIfb6FRbSqs0bJumv5JIzRYRAx3dffzAIUtDWfQ=.e10f7811-1a2e-4986-a118-6e034076205d@github.com>
 <D9L0443-Xbl9JPqlmCDhUBZQN-bs20L_XOq0PWtHWF4=.af7ced3c-31b9-46f7-95b6-38c4486d8035@github.com>
Message-ID: <Q6EkaD9rTtAvQX_I1uTs6dKHwX9_WK7D9RgnJua4zMc=.480e37a4-7f98-4f98-b49d-3f998f75cca6@github.com>

On Mon, 20 Sep 2021 14:11:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @kevinrushforth 
>>> The fix looks good. I tested it both in isolation and with PR #334 and it works on both a retina and non-retina display.
>>> 
>>> If you have time to write an automated test, that would be useful, but if not then a manual test would be OK.
>> 
>> Ok, I will try to write an automated test case which draws a sphere in a SubScene and then calculates the average color of the generated image. The test will be passed if the calculated average does not differ from the excepted average color by a certain tolerance value. I'm not sure if I will manage to do this... but I will give it a try.
>
> @andreas-heger are you able to come up with an automated test for this bug?

@kevinrushforth I've finally added a JUnit test to verify the illumination. I tested it on my MacBook with and without Retina display and also on my linux system with non HiDPI display. It only fails on the MacBook with retina display, if my fix isn't used. In all other situations (non retina display and no matter if the fix is used or not) it succeeds.

In my test class PointLightIlluminationTest, I had to use the Robot API for getting the pixel colors from the screen. In a first attempt, I tried to use the Node.snapshot method, but in this case the taken snapshot always had the correct illumination, no matter what display was used and even though the scene on the display showed the wrong illumination. I guess the snapshot method renders the node directly into an image and does not use the physical screen content and so the pixel scale factor does not play any role in this case. So, I placed the test class into the package test.robot.test3d and derived it from the existing class VisualTestBase. There are 6 tests in the class. The first checks the background color of the subscene (this test should be always succeed, no matter if the fix is applied or not... I added is just to have more security that the whole scene is really setup as desired). The other tests check the color of the displayed sphere at 4 corner pixel and one in the ce
 nter.

I hope that this test can be useful for this project.

There is one more point, not related to this pull request. I found out that the JFX project does not compile on an apple silicon mac. The -arch option of the clang compiler does not accept the value "aarch64". It must be "arm64" so that the JFX project compiles on my M1 MacBook Air. I will search if there is already a bug or create a new one in the next days.

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

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Sun Oct 24 17:23:40 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Sun, 24 Oct 2021 17:23:40 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v11]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <KgXeVfXsbcwnKt5Ktk64yu-phsl8LUfTLj-2v9q13gM=.947e7ad1-23b1-4ba6-a706-85abe19fbf41@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'openjdk:master' into fix-8255015
 - 8255015: Comments corrected
 - 8255015: Comment about copying pixel scale factors corrected
 - 8255015: Tabs removed from PointLightIllumination.java
 - Merge branch 'openjdk:master' into fix-8255015
 - 8255015: JUnit Test class added.
 - Merge branch 'openjdk:master' into fix-8255015
 - Merge branch 'openjdk:master' into fix-8255015
 - Merge branch 'openjdk:master' into fix-8255015
 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/cc995300..656cb7d8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=09-10

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From nlisker at openjdk.java.net  Sun Oct 24 17:32:01 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Sun, 24 Oct 2021 17:32:01 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
In-Reply-To: <Q6EkaD9rTtAvQX_I1uTs6dKHwX9_WK7D9RgnJua4zMc=.480e37a4-7f98-4f98-b49d-3f998f75cca6@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <nzw9tOphCjxhIQ265m-UE5bIleCrQ8saJfuCDKy_15w=.bce2d7d6-3696-4c76-b09d-2aca4ad86c66@github.com>
 <awjsHIfb6FRbSqs0bJumv5JIzRYRAx3dffzAIUtDWfQ=.e10f7811-1a2e-4986-a118-6e034076205d@github.com>
 <D9L0443-Xbl9JPqlmCDhUBZQN-bs20L_XOq0PWtHWF4=.af7ced3c-31b9-46f7-95b6-38c4486d8035@github.com>
 <Q6EkaD9rTtAvQX_I1uTs6dKHwX9_WK7D9RgnJua4zMc=.480e37a4-7f98-4f98-b49d-3f998f75cca6@github.com>
Message-ID: <zbZdCPks5dkRLPsXajhxMbORojcrHxX-D3FEJd81EhM=.3bafa95c-92f1-4826-b65c-e2a697b8a1f0@github.com>

On Sun, 24 Oct 2021 16:04:40 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

> I tried to use the Node.snapshot method, but in this case the taken snapshot always had the correct illumination, no matter what display was used and even though the scene on the display showed the wrong illumination. I guess the snapshot method renders the node directly into an image and does not use the physical screen content and so the pixel scale factor does not play any role in this case.

Maybe this is why the [lighting system tests](https://github.com/openjdk/jfx/tree/master/tests/system/src/test/java/test/javafx/scene/lighting3D) pass on Retina screens.

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

PR: https://git.openjdk.java.net/jfx/pull/531

From aghaisas at openjdk.java.net  Mon Oct 25 04:55:06 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 04:55:06 GMT
Subject: RFR: 8274669: Dialog sometimes ignores max height
In-Reply-To: <lZJ9tGD-E_JoxrLbrhCE47UNp70ABIMNZHP75T0N_u0=.23b97afc-344b-4177-a97c-87fcccbc4b9a@github.com>
References: <lZJ9tGD-E_JoxrLbrhCE47UNp70ABIMNZHP75T0N_u0=.23b97afc-344b-4177-a97c-87fcccbc4b9a@github.com>
Message-ID: <YiiBWBP3jHvpOfz0xgwhbU7TnhS2JxWas_PaMDg46vg=.9a057fd3-fccf-4711-81eb-963066d9701a@github.com>

On Sat, 2 Oct 2021 23:53:02 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a visual glitch which may happen when showing a dialog.
> When a max height is set and the pref height of the dialog content is bigger the dialog starts to flicker between the max height and the pref height.
> 
> This happens because in one case the height is not bound between the min and the max height (-> max height is ignored).
> - First layout pass: The dialog will incorrectly resize to a the pref height, which is bigger than the max height
> - Second layout pass: The dialog will correctly resize to the max height
> - repeat
> 
> The fix is to bound the height there as well (Fix in **layoutChildren()**).
> Example where a red stackpane has a bigger pref height then the max height of the dialog (see also example in ticket):
> 
> https://user-images.githubusercontent.com/66004280/135734463-03b422f4-710d-4436-9715-c91bdb768d76.mp4
> 
> * only the max height test fails before and succeeds after.

Marked as reviewed by aghaisas (Reviewer).

In this case limiting the height between min and max makes sense.

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

PR: https://git.openjdk.java.net/jfx/pull/637

From aghaisas at openjdk.java.net  Mon Oct 25 08:30:36 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 08:30:36 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <ZoOKZVvxXtcp7nd6MdVOFn6CFD-WkZxZPYAO5I7AEvw=.e3bd5dd6-3339-4e80-a4e0-37456a4a628b@github.com>

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  8271090 - fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/650/files
  - new: https://git.openjdk.java.net/jfx/pull/650/files/239c0634..9ff692db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=00-01

  Stats: 38 lines in 6 files changed: 21 ins; 12 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/650/head:pull/650

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Mon Oct 25 08:30:39 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 08:30:39 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <juiJw5tGESVbOQ1Rt_iEzA-MkLA372ZncTxnEBmtJwU=.322ec4de-a945-4778-94ae-a25c8c8d6e05@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
 <juiJw5tGESVbOQ1Rt_iEzA-MkLA372ZncTxnEBmtJwU=.322ec4de-a945-4778-94ae-a25c8c8d6e05@github.com>
Message-ID: <jKr9yXDmUxV1tU23o59As-PzJG2U36cK2KfqiNeym8k=.8313e0fc-9085-4af2-a2b6-dc3b1db558a4@github.com>

On Fri, 22 Oct 2021 15:30:36 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 91:
>> 
>>> 89:      * Default size of the {@code Box}.
>>> 90:      */
>>> 91:     public static final double DEFAULT_SIZE = 2;
>> 
>> This field was exposed by mistake probably. The other shapes don't expose theirs. I recommend to deprecate for removal.
>
> Agreed. That would need to be done in a follow-up issue, and with a CSR. So just revert this addition for this PR.

Reverted this change.
Filed [JDK-8275848](https://bugs.openjdk.java.net/browse/JDK-8275848) for addressing this.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Mon Oct 25 08:30:47 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 08:30:47 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <UvfKGRtpFRLdGI5677uyrMB_f18qmj4uzTajP5CYA-k=.5a1de02f-5920-4647-a5db-75ff6e3afe1a@github.com>
Message-ID: <4rOyz4vyKSyR9OLe-aIgrJUn8dt_8FvZkKFelKKdiKw=.047d8396-d63f-478f-83c4-79be2e93481f@github.com>

On Fri, 22 Oct 2021 14:37:14 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271090 - fix review comments
>
> modules/javafx.media/src/main/java/javafx/scene/media/Track.java line 85:
> 
>> 83:     /**
>> 84:      * Gets the <code>Map</code> containing all known metadata for this <code>Track</code>.
>> 85:      * @return the <code>Map</code> containing all known metadata for this <code>Track</code>
> 
> We tend to use `{@code }` over `<code> </code>`, but I don't think it matter.

I have just maintained the local convention used in this file.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Mon Oct 25 08:30:44 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 08:30:44 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <kg8M8SFPcipygXlU5n5XbzZLhse99ngPlC4eYOk3u30=.687cb64a-1b7c-420e-ad61-4b054545a1fe@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <kg8M8SFPcipygXlU5n5XbzZLhse99ngPlC4eYOk3u30=.687cb64a-1b7c-420e-ad61-4b054545a1fe@github.com>
Message-ID: <a92HaoYzU9hE0qwmUDiimpuFxrlE24OKIaXJJYaIGJ4=.4796c763-13f0-4406-91ab-ec51b63a940e@github.com>

On Fri, 22 Oct 2021 15:00:58 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8271090 - fix review comments
>
> modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 781:
> 
>> 779:      * Sets the {@code Scene} of this {@code Window}.
>> 780:      * @param value the {@code Scene} to be set
>> 781:      */
> 
> The javadoc tool automatically generates docs for this setter (you can see this from the generated docs without this change), including the property description, so this change will actually lose information. I'm guessing that the tool warns on this method because the setter is protected (rather than public). So we should probably file a bug against the javadoc tool. As for how to fix it, you can either suppress the warning (I'm not sure whether that's possible), or you can copy the information from the property method with a leading sentence that matches what javadoc _would_ generate.

Suppressing this warning is logical - but not possible.
As suggested, I have copied the property information and added the set method description that was generated by javadoc tool before this fix.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From kcr at openjdk.java.net  Mon Oct 25 14:33:34 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 25 Oct 2021 14:33:34 GMT
Subject: [jfx17u] RFR: 8275837: Change JavaFX release version in jfx17u to
 17.0.2
Message-ID: <Lzr5I4dpVupCQ2Lilyzna4drN7_akQL654dGxOWNEx4=.497604f3-85c9-4e05-986e-9d3be54d6346@github.com>

Bump release version in `jfx17u` repo to 17.0.2 for the start of a new release.

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

Commit messages:
 - 8275837: Change JavaFX release version in jfx17u to 17.0.2

Changes: https://git.openjdk.java.net/jfx17u/pull/15/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u&pr=15&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275837
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx17u/pull/15.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/15/head:pull/15

PR: https://git.openjdk.java.net/jfx17u/pull/15

From kcr at openjdk.java.net  Mon Oct 25 14:39:20 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 25 Oct 2021 14:39:20 GMT
Subject: [jfx11u] RFR: 8275835: Change JavaFX release version in jfx11u to
 11.0.14
Message-ID: <DaU5plsQSfI5eJSKVLxTFdZ9S_S13z240aQGo8SIWVk=.ed127efd-1bca-4edc-ad76-55e6130023d3@github.com>

Bump release version in `jfx11u` repo to 11.0.14 for the start of a new release.

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

Commit messages:
 - 8275835: Change JavaFX release version in jfx11u to 11.0.14

Changes: https://git.openjdk.java.net/jfx11u/pull/55/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=55&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275835
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx11u/pull/55.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/55/head:pull/55

PR: https://git.openjdk.java.net/jfx11u/pull/55

From jvos at openjdk.java.net  Mon Oct 25 17:29:08 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Mon, 25 Oct 2021 17:29:08 GMT
Subject: [jfx17u] RFR: 8275837: Change JavaFX release version in jfx17u to
 17.0.2
In-Reply-To: <Lzr5I4dpVupCQ2Lilyzna4drN7_akQL654dGxOWNEx4=.497604f3-85c9-4e05-986e-9d3be54d6346@github.com>
References: <Lzr5I4dpVupCQ2Lilyzna4drN7_akQL654dGxOWNEx4=.497604f3-85c9-4e05-986e-9d3be54d6346@github.com>
Message-ID: <pJEe3FZr-BZo3-I6MaAPVUkh31B8BV8LYiupgiFMTzk=.ac90f691-31c3-4c35-8afe-d6aebfc9e15f@github.com>

On Mon, 25 Oct 2021 14:27:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version in `jfx17u` repo to 17.0.2 for the start of a new release.

Marked as reviewed by jvos (Reviewer).

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

PR: https://git.openjdk.java.net/jfx17u/pull/15

From jvos at openjdk.java.net  Mon Oct 25 17:29:10 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Mon, 25 Oct 2021 17:29:10 GMT
Subject: [jfx11u] RFR: 8275835: Change JavaFX release version in jfx11u to
 11.0.14
In-Reply-To: <DaU5plsQSfI5eJSKVLxTFdZ9S_S13z240aQGo8SIWVk=.ed127efd-1bca-4edc-ad76-55e6130023d3@github.com>
References: <DaU5plsQSfI5eJSKVLxTFdZ9S_S13z240aQGo8SIWVk=.ed127efd-1bca-4edc-ad76-55e6130023d3@github.com>
Message-ID: <Ux7viWIMxwYI1WsykWwpx5pLliLXJwdWk_2gvMBdYU4=.4163242a-cd6a-468c-8ca1-2acdd13830ff@github.com>

On Mon, 25 Oct 2021 14:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version in `jfx11u` repo to 11.0.14 for the start of a new release.

Marked as reviewed by jvos (Reviewer).

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

PR: https://git.openjdk.java.net/jfx11u/pull/55

From aghaisas at openjdk.java.net  Mon Oct 25 17:42:11 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 17:42:11 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v2]
In-Reply-To: <DZzouNNxlcXiPexOELDU4oPiGiRPpan2nGH8ejqM-tI=.a2e35392-7c89-4b38-bb2e-d5a9d9e75f8c@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <K2OHVEuIGcoKhjvc6vHFiktwExS2OlUYJyucRDS9nbA=.a42e35a3-36b1-4cd6-abd9-66641f232d75@github.com>
 <DZzouNNxlcXiPexOELDU4oPiGiRPpan2nGH8ejqM-tI=.a2e35392-7c89-4b38-bb2e-d5a9d9e75f8c@github.com>
Message-ID: <7eVm2XO-DeoLEuihw1JFWrqyg4Cb1IJ4nMnzoZhCOrw=.ce67fdaa-a043-4a5a-9266-75c8a7ae5f28@github.com>

On Fri, 22 Oct 2021 13:37:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   javadoc minor corrections
>
> modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line 470:
> 
>> 468:      * {@code CssMetaData} of its superclasses.
>> 469:      * @return the {@code CssMetaData}
>> 470:      * @since JavaFX 8.0
> 
> The class already has an `@since JavaFX 8.0` tag so this is unnecessary. It's also unrelated to this fix (and we would need a CSR for any changes to `@since` tags).

OK. I will remove this since tag.

> modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java line 160:
> 
>> 158:     /**
>> 159:      * Focuses the item at the given index.
>> 160:      * @param index the index of the item that needs to be focused
> 
> Minor: I recommend removing "that needs" from this `@param`.

Done.

> modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 201:
> 
>> 199:      * this specific {@code PopupControl}.
>> 200:      * @return the {@code StringProperty} representing the CSS style
>> 201:      */
> 
> I recommend taking the information from the setter and copying it here. The docs can/should then be removed from both the setter and the getter. The first sentence should describe the property so does not need to start with "Gets the ...". You can add the information about `null` being turned into the empty string as a sentence in the Description. The `@defaultValue empty string` means that the information in the `@return` of the getter is unnecessary.

I could move the description from the setter to the javadoc of `getStyle()` method as suggested. A `@return` is still needed for `getStyle()` as not to get the javadoc warning.

> modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 47:
> 
>> 45:     /**
>> 46:      * Gets the default singleton {@code SortEvent}.
>> 47:      * @param <C> the type of control
> 
> Can you also add this `@param` tag to the class description? I'm a little surprised that javadoc doesn't flag it as missing.

Added.

> modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 59:
> 
>> 57:     /**
>> 58:      * Constructs a new {@code Event} with the specified event source, target
>> 59:      * and type. If the source or target is set to {@code null}, it is replaced
> 
> That should be "a new `{@code SortEvent}` ...". Also, since there is no type parameter, you should remove "and type" (and replace the comma after source with "and").

Done.

> modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line 63:
> 
>> 61:      *
>> 62:      * @param source the event source which sent the event
>> 63:      * @param target the target of the scroll to operation
> 
> That should be "the target of the event".

Changed.

> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 405:
> 
>> 403:     }
>> 404: 
>> 405:     public final DoubleProperty tabMaxWidthProperty() {
> 
> The best practice for properties is to put the description on exactly one of the `xxx` private field or the `xxxProperty` method, and not on the setter or getter (unless there is a specific need to document something special in the setter or getter). There is a separate JBS issue, [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085), tracking the fix for the `maxWidth` and `maxHeight` properties.
> 
> You can either revert this change, in which case we'll need a new PR for that issue (it can be done later), or else modify this change to match the best practice as noted in JDK-8271085 and add that issue to this PR. The latter will require addressing the other methods in this file as noted in that JBS bug.

I prefer reverting this and handling it separately under a separate PR.

> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 501:
> 
>> 499:     }
>> 500: 
>> 501:     public final DoubleProperty tabMaxHeightProperty() {
> 
> Same comment as above. This needs to be reverted or modified.

I prefer reverting this and handling it separately under a separate PR.

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

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Mon Oct 25 17:47:38 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 25 Oct 2021 17:47:38 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v3]
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <vHrnTXLUSuWHGtIyq87JZSfzlQlZgX695h7wMPbOhH0=.91399f17-5876-43d8-b126-4241ae77a659@github.com>

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/646/files
  - new: https://git.openjdk.java.net/jfx/pull/646/files/38563835..7cc2de52

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=01-02

  Stats: 124 lines in 8 files changed: 48 ins; 21 del; 55 mod
  Patch: https://git.openjdk.java.net/jfx/pull/646.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/646/head:pull/646

PR: https://git.openjdk.java.net/jfx/pull/646

From mhanl at openjdk.java.net  Mon Oct 25 20:58:09 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Mon, 25 Oct 2021 20:58:09 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v3]
In-Reply-To: <6Yizd_tITIxMk8FQyqNQEsLQButJKy3MTQGro0ax1N4=.ec406d6e-05fc-4d00-86a0-0c01db1e9d6e@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <6Yizd_tITIxMk8FQyqNQEsLQButJKy3MTQGro0ax1N4=.ec406d6e-05fc-4d00-86a0-0c01db1e9d6e@github.com>
Message-ID: <9u3vBwSFZ75jWTwQMiI77DdQQyJkSqQjbZMFoslgFP8=.0ef25bac-7ff3-4c1e-bd10-6ebb2d721af5@github.com>

On Fri, 22 Oct 2021 10:36:24 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
>> 
>> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
>> 
>> Added/unignored cell tests that are failing/passing before/after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   next try with fixing the formatting

Looks good. ??

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

Marked as reviewed by mhanl (Author).

PR: https://git.openjdk.java.net/jfx/pull/638

From mariushanl at web.de  Mon Oct 25 22:23:27 2021
From: mariushanl at web.de (Marius Hanl)
Date: Tue, 26 Oct 2021 00:23:27 +0200
Subject: Aw: Easier handling of ObservableList/Set/Map change events
In-Reply-To: <CAJEpuXQW_TLdbOmes-L0LC_yy=gfQs3LHAMzWiWt6mS7ff37aw@mail.gmail.com>
References: <CAJEpuXQW_TLdbOmes-L0LC_yy=gfQs3LHAMzWiWt6mS7ff37aw@mail.gmail.com>
Message-ID: <trinity-63cbf6b8-34bc-47d2-9157-7d9d68f201d9-1635200607812@3c-app-webde-bs42>

   I like this idea.
   Pretty sure some listener I wrote won't handle a permutation correctly.

   I may have one question: Is there something that needs to be done in
   case of an update (wasUpdated)?

   -- Marius

   Gesendet: Mittwoch, 20. Oktober 2021 um 21:07 Uhr
   Von: "Michael Strau?" <michaelstrau2 at gmail.com>
   An: "openjfx-dev at openjdk.java.net List" <openjfx-dev at openjdk.java.net>
   Betreff: Easier handling of ObservableList/Set/Map change events
   I'd like to gauge interest on a small feature addition for JavaFX
   collections.
   ObservableList (and similarly, ObservableSet/ObservableMap) allows
   developers to register ListChangeListeners to observe changes to the
   list. In some cases, these changes are applied to another list or
   projected into a different form.
   Implementing ListChangeListener correctly is quite tricky, especially
   if the ObservableList implementation also fires "replace" and
   "permutate" events. As a result, it is very easy to implement this
   interface wrongly, which often goes undetected when the implementation
   is only tested against basic operations like "add" and "remove".
   Maybe we could make it easier for developers to get it right more of
   the time, by offering pre-built adapters for ListChangeListener,
   SetChangeListener and MapChangeListener.
   Here's what that could look like:
   public abstract class ListChangeListenerAdapter<E> implements
   ListChangeListener<E> {
   // Basic methods
   public abstract void onAdded(int index, E element);
   public abstract void onRemoved(int index);
   // Optional methods
   public void onAdded(int index, List<? extends E> elements);
   public void onRemoved(int from, int to);
   public void onReplaced(int index, E element);
   public void onUpdated(int index, E element);
   }
   An implementation of this adapter must at the very least implement the
   basic `onAdded` and `onRemoved` methods. The adapter will then
   correctly map all other change events ("replace" and "permutate") to
   these methods. All adapter methods will always be called in exactly
   the right order, such that they always refer to the current state of
   the list.
   An adapter implementation can improve performance characteristics by
   overriding the optional `onAdded`, `onRemoved` and `onReplaced`
   methods (which map to `addAll`, `remove` and `set` of the List
   interface). Optional methods are implemented by default to throw a
   private exception in ListChangeListenerAdapter, which is used to
   discover whether the methods are overridden and should be called
   instead of the basic methods.

From kcr at openjdk.java.net  Mon Oct 25 23:18:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 25 Oct 2021 23:18:15 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v3]
In-Reply-To: <vHrnTXLUSuWHGtIyq87JZSfzlQlZgX695h7wMPbOhH0=.91399f17-5876-43d8-b126-4241ae77a659@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <vHrnTXLUSuWHGtIyq87JZSfzlQlZgX695h7wMPbOhH0=.91399f17-5876-43d8-b126-4241ae77a659@github.com>
Message-ID: <USL_DEb6K9SZZs0HUTufRAQtlTO0yfgpe0zTBKOrIlc=.feb6c11c-f7d9-4e12-b3ee-c70ad6d4a7fc@github.com>

On Mon, 25 Oct 2021 17:47:38 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Two minor comments. The rest looks great.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 179:

> 177:      * HTML element. Note that, like the HTML style attribute, this
> 178:      * variable contains style properties and values and not the
> 179:      * selector portion of a style rule.

It would be good to add a sentence here with the information (which was formerly in the getter) that a value of `null` is converted to the empty string.

modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 508:

> 506:     * <p>The maximum height of the tabs in the TabPane.</p>
> 507:     * @return the maximum height of the tabs
> 508:     */

In reverting this, you introduced a whitespace (indentation) change.

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

PR: https://git.openjdk.java.net/jfx/pull/646

From kcr at openjdk.java.net  Mon Oct 25 23:30:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 25 Oct 2021 23:30:16 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <ZoOKZVvxXtcp7nd6MdVOFn6CFD-WkZxZPYAO5I7AEvw=.e3bd5dd6-3339-4e80-a4e0-37456a4a628b@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <ZoOKZVvxXtcp7nd6MdVOFn6CFD-WkZxZPYAO5I7AEvw=.e3bd5dd6-3339-4e80-a4e0-37456a4a628b@github.com>
Message-ID: <xi7wyrjg1ZIZaYelV8sN7gE938YDWOOD1UfF71rSVLA=.2f14addd-f6cc-49e1-b77b-2d9ccdce622d@github.com>

On Mon, 25 Oct 2021 08:30:36 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8271090 - fix review comments

Looks good with a couple suggestions on `setScene`. We might want to also file a follow-up javadoc bug so we can get rid of the javadocs for that method altogether.

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 781:

> 779:      * Sets the value of the {@code scene} property.
> 780:      *
> 781:      * The {@code Scene} to be rendered on this {@code Window}. There can only

Can you add a `<p>` tag here? This will be closer to what an implicitly-generated setter would do.

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 798:

> 796:      * @defaultValue null
> 797:      *
> 798:      * @param value the value for the {@code scene} property

Can you add the following tags?
`@see getScene()`
`@see sceneProperty()`

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

PR: https://git.openjdk.java.net/jfx/pull/650

From kcr at openjdk.java.net  Mon Oct 25 23:58:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 25 Oct 2021 23:58:15 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v11]
In-Reply-To: <KgXeVfXsbcwnKt5Ktk64yu-phsl8LUfTLj-2v9q13gM=.947e7ad1-23b1-4ba6-a706-85abe19fbf41@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <KgXeVfXsbcwnKt5Ktk64yu-phsl8LUfTLj-2v9q13gM=.947e7ad1-23b1-4ba6-a706-85abe19fbf41@github.com>
Message-ID: <CreT25A6esVkqEM8g-YJ3S0xqAREP3CQC3T2634bTXw=.d7759ca4-2b37-4dc3-a8ec-6bd7ae981ae3@github.com>

On Sun, 24 Oct 2021 17:23:40 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

>> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
>> 
>> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)
>
> Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into fix-8255015
>  - 8255015: Comments corrected
>  - 8255015: Comment about copying pixel scale factors corrected
>  - 8255015: Tabs removed from PointLightIllumination.java
>  - Merge branch 'openjdk:master' into fix-8255015
>  - 8255015: JUnit Test class added.
>  - Merge branch 'openjdk:master' into fix-8255015
>  - Merge branch 'openjdk:master' into fix-8255015
>  - Merge branch 'openjdk:master' into fix-8255015
>  - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays

The fix and the test looks good. I left a couple minor comments on the test.

I ran the test on macOS with retina. I'll double-check on the other platforms, but I think this is about ready to go.

tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 67:

> 65:     private static final int    LOWER_CORNER_Y     = (int) (SCENE_WIDTH_HEIGHT * (1 - CORNER_FACTOR));
> 66:     private static final double COLOR_TOLERANCE    = 0.07;
> 67:     private static Scene testScene;

This is created on one thread and tested on another (to see whether it's already been created), so I recommend making it `volatile` (i.e., `private static volatile ...`). Also, you might want to explicitly set it to `null` since you rely on it (yes, I know `null` is the default).

tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 180:

> 178:         return new Scene(new Group(subScene), SCENE_WIDTH_HEIGHT, SCENE_WIDTH_HEIGHT);
> 179:     }
> 180: }

Minor: there should be a new line at the end of the file.

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

PR: https://git.openjdk.java.net/jfx/pull/531

From mhanl at openjdk.java.net  Tue Oct 26 04:35:14 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 26 Oct 2021 04:35:14 GMT
Subject: Integrated: 8274669: Dialog sometimes ignores max height
In-Reply-To: <lZJ9tGD-E_JoxrLbrhCE47UNp70ABIMNZHP75T0N_u0=.23b97afc-344b-4177-a97c-87fcccbc4b9a@github.com>
References: <lZJ9tGD-E_JoxrLbrhCE47UNp70ABIMNZHP75T0N_u0=.23b97afc-344b-4177-a97c-87fcccbc4b9a@github.com>
Message-ID: <JffstwsEWjNKKGqd5xXo5zwxmH_AqCl3yfn-kWdLuNw=.be310eb1-05b2-4ddf-ad9b-e0a970e56b20@github.com>

On Sat, 2 Oct 2021 23:53:02 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a visual glitch which may happen when showing a dialog.
> When a max height is set and the pref height of the dialog content is bigger the dialog starts to flicker between the max height and the pref height.
> 
> This happens because in one case the height is not bound between the min and the max height (-> max height is ignored).
> - First layout pass: The dialog will incorrectly resize to a the pref height, which is bigger than the max height
> - Second layout pass: The dialog will correctly resize to the max height
> - repeat
> 
> The fix is to bound the height there as well (Fix in **layoutChildren()**).
> Example where a red stackpane has a bigger pref height then the max height of the dialog (see also example in ticket):
> 
> https://user-images.githubusercontent.com/66004280/135734463-03b422f4-710d-4436-9715-c91bdb768d76.mp4
> 
> * only the max height test fails before and succeeds after.

This pull request has now been integrated.

Changeset: 717cfdc8
Author:    Marius Hanl <mhanl at openjdk.org>
Committer: Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/717cfdc85817aee57d5326e592340c849382d7a4
Stats:     108 lines in 2 files changed: 107 ins; 0 del; 1 mod

8274669: Dialog sometimes ignores max height

Reviewed-by: aghaisas

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

PR: https://git.openjdk.java.net/jfx/pull/637

From aghaisas at openjdk.java.net  Tue Oct 26 06:20:14 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 Oct 2021 06:20:14 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v3]
In-Reply-To: <USL_DEb6K9SZZs0HUTufRAQtlTO0yfgpe0zTBKOrIlc=.feb6c11c-f7d9-4e12-b3ee-c70ad6d4a7fc@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <vHrnTXLUSuWHGtIyq87JZSfzlQlZgX695h7wMPbOhH0=.91399f17-5876-43d8-b126-4241ae77a659@github.com>
 <USL_DEb6K9SZZs0HUTufRAQtlTO0yfgpe0zTBKOrIlc=.feb6c11c-f7d9-4e12-b3ee-c70ad6d4a7fc@github.com>
Message-ID: <fbEiGeRlPAvwvLGSaeXBJrsTCCeHH7p4rvTIasU1YuU=.5d9012d4-314b-4f06-ba7c-a2339c0dc7ce@github.com>

On Mon, 25 Oct 2021 22:53:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 179:
> 
>> 177:      * HTML element. Note that, like the HTML style attribute, this
>> 178:      * variable contains style properties and values and not the
>> 179:      * selector portion of a style rule.
> 
> It would be good to add a sentence here with the information (which was formerly in the getter) that a value of `null` is converted to the empty string.

Added.

> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line 508:
> 
>> 506:     * <p>The maximum height of the tabs in the TabPane.</p>
>> 507:     * @return the maximum height of the tabs
>> 508:     */
> 
> In reverting this, you introduced a whitespace (indentation) change.

Fixed.

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

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Tue Oct 26 06:24:35 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 Oct 2021 06:24:35 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v4]
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/646/files
  - new: https://git.openjdk.java.net/jfx/pull/646/files/7cc2de52..b4d5dc4f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=02-03

  Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/646.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/646/head:pull/646

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Tue Oct 26 09:54:43 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 Oct 2021 09:54:43 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/650/files
  - new: https://git.openjdk.java.net/jfx/pull/650/files/9ff692db..e4d337c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=01-02

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/650/head:pull/650

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Tue Oct 26 09:54:44 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 Oct 2021 09:54:44 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v2]
In-Reply-To: <xi7wyrjg1ZIZaYelV8sN7gE938YDWOOD1UfF71rSVLA=.2f14addd-f6cc-49e1-b77b-2d9ccdce622d@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <ZoOKZVvxXtcp7nd6MdVOFn6CFD-WkZxZPYAO5I7AEvw=.e3bd5dd6-3339-4e80-a4e0-37456a4a628b@github.com>
 <xi7wyrjg1ZIZaYelV8sN7gE938YDWOOD1UfF71rSVLA=.2f14addd-f6cc-49e1-b77b-2d9ccdce622d@github.com>
Message-ID: <7_S2fW9NqBPYUeBtp6b03Ow9swTTqrHeiAFAws6pxj8=.3f7908b8-09ef-4c84-ad42-9f04f0fd8efa@github.com>

On Mon, 25 Oct 2021 23:27:19 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Looks good with a couple suggestions on `setScene`. We might want to also file a follow-up javadoc bug so we can get rid of the javadocs for that method altogether.

I have filed - [JDK-8275910](https://bugs.openjdk.java.net/browse/JDK-8275910) for this.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From jpereda at openjdk.java.net  Tue Oct 26 11:13:24 2021
From: jpereda at openjdk.java.net (Jose Pereda)
Date: Tue, 26 Oct 2021 11:13:24 GMT
Subject: RFR: 8275911: Keyboard doesn't show when tapping inside an iOS text
 input control
Message-ID: <uzzdKkob2d37_tQGA51Ohy1SYKQazmZ_5EkXtjKj2qk=.6b39be86-64eb-40fa-9bdb-78cbcbd0e3e3@github.com>

After [JDK-8245053](https://bugs.openjdk.java.net/browse/JDK-8245053) for Android, this PR applies the same approach on iOS: tapping on a text input control on iOS shows the keyboard, which hides after the control loses the focus. 

Now, both platforms have the same behaviour.

Tested on an iOS device.

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

Commit messages:
 - Show iOS keyboard when user taps on TextInput controls

Changes: https://git.openjdk.java.net/jfx/pull/653/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=653&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8275911
  Stats: 90 lines in 2 files changed: 60 ins; 2 del; 28 mod
  Patch: https://git.openjdk.java.net/jfx/pull/653.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/653/head:pull/653

PR: https://git.openjdk.java.net/jfx/pull/653

From kcr at openjdk.java.net  Tue Oct 26 11:37:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 Oct 2021 11:37:15 GMT
Subject: [jfx17u] Integrated: 8275837: Change JavaFX release version in jfx17u
 to 17.0.2
In-Reply-To: <Lzr5I4dpVupCQ2Lilyzna4drN7_akQL654dGxOWNEx4=.497604f3-85c9-4e05-986e-9d3be54d6346@github.com>
References: <Lzr5I4dpVupCQ2Lilyzna4drN7_akQL654dGxOWNEx4=.497604f3-85c9-4e05-986e-9d3be54d6346@github.com>
Message-ID: <ozleTaeD-oopF2r7xJTJnzL3gSeziZfl0KFCYSLabjo=.85652f01-c253-4210-a18a-7decc160a0bb@github.com>

On Mon, 25 Oct 2021 14:27:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version in `jfx17u` repo to 17.0.2 for the start of a new release.

This pull request has now been integrated.

Changeset: 99a629b4
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx17u/commit/99a629b4006b03d09b8a5d4a9030f9ea963a605f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8275837: Change JavaFX release version in jfx17u to 17.0.2

Reviewed-by: jvos

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

PR: https://git.openjdk.java.net/jfx17u/pull/15

From kcr at openjdk.java.net  Tue Oct 26 11:43:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 Oct 2021 11:43:15 GMT
Subject: [jfx11u] Integrated: 8275835: Change JavaFX release version in jfx11u
 to 11.0.14
In-Reply-To: <DaU5plsQSfI5eJSKVLxTFdZ9S_S13z240aQGo8SIWVk=.ed127efd-1bca-4edc-ad76-55e6130023d3@github.com>
References: <DaU5plsQSfI5eJSKVLxTFdZ9S_S13z240aQGo8SIWVk=.ed127efd-1bca-4edc-ad76-55e6130023d3@github.com>
Message-ID: <oQetc746VyWvGhsHuD07vb4p5o9cyVuC4-oRIO_orm0=.82490062-708d-4e84-8d95-18aa6841f7bd@github.com>

On Mon, 25 Oct 2021 14:34:39 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Bump release version in `jfx11u` repo to 11.0.14 for the start of a new release.

This pull request has now been integrated.

Changeset: e253fd94
Author:    Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx11u/commit/e253fd940710b421a01c85ad3502407d0dea6794
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8275835: Change JavaFX release version in jfx11u to 11.0.14

Reviewed-by: jvos

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

PR: https://git.openjdk.java.net/jfx11u/pull/55

From aghaisas at openjdk.java.net  Tue Oct 26 12:15:12 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 26 Oct 2021 12:15:12 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
In-Reply-To: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
Message-ID: <vraMbMiA0FveYHOEbHWptq9RLvshSFtNTMPcsSmlWBQ=.8eb14fc0-9feb-4cd0-b557-e8269c4c225b@github.com>

On Fri, 24 Sep 2021 16:01:38 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> Cleanup of Tree-/TableRowSkin to support switching skins
> 
> The misbehavior/s
> - memory leaks due to manually registered listeners that were not removed
> - side-effects due to listeners still active on old skin (like NPEs)
> 
> Fix
> - use skin api for all listener registration (for automatic removal in dispose)
> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))
> 
> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins.
> 
> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)

I have two comments regarding possibility of introducing a regression. Can you please confirm that it does not cause any side effect?
Rest of the fix looks ok.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 134:

> 132:                 // that when it changes, we can appropriately add / remove cells that may or may not
> 133:                 // be required (because we remove all cells that are not visible).
> 134:                 registerChangeListener(getVirtualFlow().widthProperty(), e -> tableView.requestLayout());

If this listener is removed, then is there a chance of reintroducing [JDK-8144500](https://bugs.openjdk.java.net/browse/JDK-8144500)?
Unfortunately, there is no test added for that bug.. so it is difficult to catch regression, if any.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 154:

> 152:                 // that when it changes, we can appropriately add / remove cells that may or may not
> 153:                 // be required (because we remove all cells that are not visible).
> 154:                 registerChangeListener(getVirtualFlow().widthProperty(), e -> treeTableView.requestLayout());

Same comment as in TableRowSkin regarding this listener.

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

PR: https://git.openjdk.java.net/jfx/pull/632

From mhanl at openjdk.java.net  Tue Oct 26 12:18:23 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Tue, 26 Oct 2021 12:18:23 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
Message-ID: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>

This problem can happen when using multiple instances with different jfx early access (ea) versions.

Example: 
Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
Instance 1 is started (and will cache and use libraries), then instance 2. 
Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.

The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).

Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
With this the folders will be named 18-ea+1 and 18-ea+4.

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

Commit messages:
 - 8222455: Using javafx.runtime.version as cache directory name so that different ea versions use the same folder

Changes: https://git.openjdk.java.net/jfx/pull/654/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=654&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8222455
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/654.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/654/head:pull/654

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Tue Oct 26 12:18:23 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 Oct 2021 12:18:23 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <jq7wcfAMj6bqiRvpzjk6QYXq5GWU0_Xy1P1OmSMN1Us=.09401844-832b-4a9c-a2a5-a961170f2e50@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

This is a simple change, but it has some implications that @johanvos will need to approve.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Tue Oct 26 13:01:28 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 Oct 2021 13:01:28 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v4]
In-Reply-To: <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>
Message-ID: <SiLCTCgzqUFqU65DAphxq2Fpwp-rjLJk3_VUxZSbiNc=.5740cb13-0be6-48b1-9553-41c99d44b766@github.com>

On Tue, 26 Oct 2021 06:24:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/646

From duke at openjdk.java.net  Tue Oct 26 19:48:41 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Tue, 26 Oct 2021 19:48:41 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v12]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  8255015: testScene variable must be volatile and new line at the end of the file added

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/656cb7d8..1598c604

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=10-11

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Tue Oct 26 19:48:47 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Tue, 26 Oct 2021 19:48:47 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v11]
In-Reply-To: <CreT25A6esVkqEM8g-YJ3S0xqAREP3CQC3T2634bTXw=.d7759ca4-2b37-4dc3-a8ec-6bd7ae981ae3@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <KgXeVfXsbcwnKt5Ktk64yu-phsl8LUfTLj-2v9q13gM=.947e7ad1-23b1-4ba6-a706-85abe19fbf41@github.com>
 <CreT25A6esVkqEM8g-YJ3S0xqAREP3CQC3T2634bTXw=.d7759ca4-2b37-4dc3-a8ec-6bd7ae981ae3@github.com>
Message-ID: <itlLFORRGbCjrsPFskbyZSEu-W_CSZuTcbutdSEsVWI=.fc4eb19e-bc20-4b61-bf03-403dd5c038d2@github.com>

On Mon, 25 Oct 2021 23:50:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into fix-8255015
>>  - 8255015: Comments corrected
>>  - 8255015: Comment about copying pixel scale factors corrected
>>  - 8255015: Tabs removed from PointLightIllumination.java
>>  - Merge branch 'openjdk:master' into fix-8255015
>>  - 8255015: JUnit Test class added.
>>  - Merge branch 'openjdk:master' into fix-8255015
>>  - Merge branch 'openjdk:master' into fix-8255015
>>  - Merge branch 'openjdk:master' into fix-8255015
>>  - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays
>
> tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 67:
> 
>> 65:     private static final int    LOWER_CORNER_Y     = (int) (SCENE_WIDTH_HEIGHT * (1 - CORNER_FACTOR));
>> 66:     private static final double COLOR_TOLERANCE    = 0.07;
>> 67:     private static Scene testScene;
> 
> This is created on one thread and tested on another (to see whether it's already been created), so I recommend making it `volatile` (i.e., `private static volatile ...`). Also, you might want to explicitly set it to `null` since you rely on it (yes, I know `null` is the default).

@kevinrushforth Thanks for the hint about about making the variable volatile! I've just updated the class accordingly.

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

PR: https://git.openjdk.java.net/jfx/pull/531

From kcr at openjdk.java.net  Tue Oct 26 23:11:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 26 Oct 2021 23:11:13 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
Message-ID: <0bVUp6hvJPIzX2bfXnVYLNSgPd9RC3G-eqztc-fs52w=.546abe36-f049-41c2-8f85-3b810cdd8a45@github.com>

On Tue, 26 Oct 2021 09:54:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/650

From kcr at openjdk.java.net  Wed Oct 27 00:49:15 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 27 Oct 2021 00:49:15 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v12]
In-Reply-To: <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>
Message-ID: <fAFzJk_ZVlm8ka2U5vYdI-j5Q28W-CEnBBctR64estU=.3a7a3ba5-4a90-4490-86a5-bad840f1bd56@github.com>

On Tue, 26 Oct 2021 19:48:41 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

>> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
>> 
>> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)
>
> Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255015: testScene variable must be volatile and new line at the end of the file added

Looks good. I ran the test on all three platforms. On macOS I ran the test on both a retina and non-retina screen.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/531

From jvos at openjdk.java.net  Wed Oct 27 08:15:17 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Wed, 27 Oct 2021 08:15:17 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <AuXXb5o9rZTaT3AfdQylxWiz2BypxLg3A8Fc_EtHlMg=.60edff4b-a874-48ea-b287-aef23c28af0f@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

This looks like a good solution, and I agree it fixes the issue.
I have 2 minor concerns:
1. Are we sure there are no platform-specific restrictions when using a `+` in a filename?
2. Testing this is probably difficult. We can only test it if a build is created (and the versionInfo is set). 

I think the second concern can not be handled by our current test battery, but we do some smoke tests before releasing the maven repository, which should be able to detect this.
If you are confident about the first concern, I think we're all good on this.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From arapte at openjdk.java.net  Wed Oct 27 09:32:15 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 27 Oct 2021 09:32:15 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
Message-ID: <5v4ePALQG0f5yPMCQdKbxCaCqPoHXrgBTAbJGKCmSSg=.bf8713d1-a134-4f85-b5ee-26aa3450902f@github.com>

On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replacements of more immutable collections.
>> 
>> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports

Looks good to me.

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

Marked as reviewed by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/627

From fastegal at openjdk.java.net  Wed Oct 27 09:56:46 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 27 Oct 2021 09:56:46 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
Message-ID: <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>

> Cleanup of Tree-/TableRowSkin to support switching skins
> 
> The misbehavior/s
> - memory leaks due to manually registered listeners that were not removed
> - side-effects due to listeners still active on old skin (like NPEs)
> 
> Fix
> - use skin api for all listener registration (for automatic removal in dispose)
> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))
> 
> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins.
> 
> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)

Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:

  re-added forgotten code comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/632/files
  - new: https://git.openjdk.java.net/jfx/pull/632/files/52e18d22..5402e1fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=632&range=00-01

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/632.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/632/head:pull/632

PR: https://git.openjdk.java.net/jfx/pull/632

From fastegal at openjdk.java.net  Wed Oct 27 09:56:51 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Wed, 27 Oct 2021 09:56:51 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <vraMbMiA0FveYHOEbHWptq9RLvshSFtNTMPcsSmlWBQ=.8eb14fc0-9feb-4cd0-b557-e8269c4c225b@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
 <vraMbMiA0FveYHOEbHWptq9RLvshSFtNTMPcsSmlWBQ=.8eb14fc0-9feb-4cd0-b557-e8269c4c225b@github.com>
Message-ID: <IeZGths5pGtAhO0mXixrF-uc2ZbZE1IFCUb7KuxZ_2I=.78925dfc-1d11-4c62-833c-9efb09d430a4@github.com>

On Tue, 26 Oct 2021 12:07:23 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   re-added forgotten code comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 134:
> 
>> 132:                 // that when it changes, we can appropriately add / remove cells that may or may not
>> 133:                 // be required (because we remove all cells that are not visible).
>> 134:                 registerChangeListener(getVirtualFlow().widthProperty(), e -> tableView.requestLayout());
> 
> If this listener is removed, then is there a chance of reintroducing [JDK-8144500](https://bugs.openjdk.java.net/browse/JDK-8144500)?
> Unfortunately, there is no test added for that bug.. so it is difficult to catch regression, if any.

hmm .. the listener is not removed, its registration is moved to updateTableViewSkin. There are tests covering that it really is still registered :)

Forgot to move the old code comment, though. Re-added.

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 154:
> 
>> 152:                 // that when it changes, we can appropriately add / remove cells that may or may not
>> 153:                 // be required (because we remove all cells that are not visible).
>> 154:                 registerChangeListener(getVirtualFlow().widthProperty(), e -> treeTableView.requestLayout());
> 
> Same comment as in TableRowSkin regarding this listener.

same comment as to TableRowSkin :)

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

PR: https://git.openjdk.java.net/jfx/pull/632

From arapte at openjdk.java.net  Wed Oct 27 10:49:14 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Wed, 27 Oct 2021 10:49:14 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v12]
In-Reply-To: <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>
Message-ID: <Pw-FSpaWV0YZbhPwq9WAIWmV8sTHQLirL4kAS5J_AFw=.ddc79c71-ebee-4a4c-ba16-582c04309e21@github.com>

On Tue, 26 Oct 2021 19:48:41 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

>> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
>> 
>> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)
>
> Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255015: testScene variable must be volatile and new line at the end of the file added

Looks good to me. The copyright year in test file needs  to be changed. Along with it please fix the suggested minor typo.

tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved.

It should have only one copyright year: 2021.
-> `* Copyright (c) 2021, Oracle and/o`

tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 148:

> 146:      * Creates a new scene with a subscene which contains a perspective camera and a sphere
> 147:      * Although this test class checks the pointlight illumination, there is no explicit pointlight
> 148:      * in the scene. For the test, it is sufficient to use the default pointlight which is created

minor: Please include this small correction along with the copyright year change. 
pointlight -> point light

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

Changes requested by arapte (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/531

From aghaisas at openjdk.java.net  Wed Oct 27 14:44:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 Oct 2021 14:44:16 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
 <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
Message-ID: <e5LIJ0DpoBD7_p-URe24-TcKDjVbxRd9V9ONWSkZQqg=.840e1164-5603-4928-8190-96dd5543ff9e@github.com>

On Wed, 27 Oct 2021 09:56:46 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Cleanup of Tree-/TableRowSkin to support switching skins
>> 
>> The misbehavior/s
>> - memory leaks due to manually registered listeners that were not removed
>> - side-effects due to listeners still active on old skin (like NPEs)
>> 
>> Fix
>> - use skin api for all listener registration (for automatic removal in dispose)
>> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))
>> 
>> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins.
>> 
>> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-added forgotten code comments

Marked as reviewed by aghaisas (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/632

From aghaisas at openjdk.java.net  Wed Oct 27 14:44:17 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 Oct 2021 14:44:17 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <IeZGths5pGtAhO0mXixrF-uc2ZbZE1IFCUb7KuxZ_2I=.78925dfc-1d11-4c62-833c-9efb09d430a4@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
 <vraMbMiA0FveYHOEbHWptq9RLvshSFtNTMPcsSmlWBQ=.8eb14fc0-9feb-4cd0-b557-e8269c4c225b@github.com>
 <IeZGths5pGtAhO0mXixrF-uc2ZbZE1IFCUb7KuxZ_2I=.78925dfc-1d11-4c62-833c-9efb09d430a4@github.com>
Message-ID: <j1uD0H0K4z5-lnfrzXm_dWwzwfMheIg6ZnBtdH62BAQ=.1d7d9f11-4235-4714-ab68-359f424aa795@github.com>

On Wed, 27 Oct 2021 09:50:32 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableRowSkin.java line 134:
>> 
>>> 132:                 // that when it changes, we can appropriately add / remove cells that may or may not
>>> 133:                 // be required (because we remove all cells that are not visible).
>>> 134:                 registerChangeListener(getVirtualFlow().widthProperty(), e -> tableView.requestLayout());
>> 
>> If this listener is removed, then is there a chance of reintroducing [JDK-8144500](https://bugs.openjdk.java.net/browse/JDK-8144500)?
>> Unfortunately, there is no test added for that bug.. so it is difficult to catch regression, if any.
>
> hmm .. the listener is not removed, its registration is moved to updateTableViewSkin. There are tests covering that it really is still registered :)
> 
> Forgot to move the old code comment, though. Re-added.

Thanks for the explanation.

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

PR: https://git.openjdk.java.net/jfx/pull/632

From aghaisas at openjdk.java.net  Wed Oct 27 14:47:15 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 Oct 2021 14:47:15 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
Message-ID: <vV5zdjwurNmKpmJ-XwFT4aEDzSTFi4jAuwvSF9ffvRQ=.05fce795-5b71-41c0-ad2e-395c8032c0ce@github.com>

On Tue, 26 Oct 2021 09:54:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

@nlisker, can you please take a look and approve?

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

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Wed Oct 27 14:48:18 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Wed, 27 Oct 2021 14:48:18 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v4]
In-Reply-To: <25kwolxFeJq5O3VLwd96nLVFQ0w0KU-ixhTantm5Pfg=.9a8d5bbf-5daf-4000-8464-2346b6f19990@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <25kwolxFeJq5O3VLwd96nLVFQ0w0KU-ixhTantm5Pfg=.9a8d5bbf-5daf-4000-8464-2346b6f19990@github.com>
Message-ID: <96J05fnPsYfnRdNbzeK2gofkqbfbQOdJwB7rjQ34dMI=.f4ecf11f-d526-4630-a5c8-34b8fa5ecbdc@github.com>

On Wed, 20 Oct 2021 15:45:52 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> Took a quick look at the new docs. I didn't check the resulting HTML or the corrected of the description, just format and grammar.

@nlisker, can you please take a look and approve?

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

PR: https://git.openjdk.java.net/jfx/pull/646

From nlisker at openjdk.java.net  Wed Oct 27 15:55:28 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 27 Oct 2021 15:55:28 GMT
Subject: RFR: 8272808: Update constant collections to use the new immutable
 collections - leftovers [v2]
In-Reply-To: <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
References: <uALErJgVKfWYQvGvaCtvfpRG_-8R-jlt_e0Uvqox_H0=.9fa508e5-997a-4bee-84e4-c9954d3b4af5@github.com>
 <mY1z98_xEoo2iftCKzQ4Jpa0x4beO46TpYjozeUbpkw=.3880db06-5bf7-4f9d-80ec-bf92744ef75c@github.com>
Message-ID: <29RU2DRp0ngvHRRdan_6M3HOxFpUi7XHRKbhol-uzU8=.afab9cba-a44d-4352-8209-edf3b833ea09@github.com>

On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Replacements of more immutable collections.
>> 
>> One thing I found was that the field `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if that's indeed the case.
>
> Nir Lisker has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused imports

@johanvos Can you comment on `idMap` in `com.sun.java.scene.web.WebViewHelper.WebView`?

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

PR: https://git.openjdk.java.net/jfx/pull/627

From mhanl at openjdk.java.net  Wed Oct 27 16:05:15 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Wed, 27 Oct 2021 16:05:15 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <AuXXb5o9rZTaT3AfdQylxWiz2BypxLg3A8Fc_EtHlMg=.60edff4b-a874-48ea-b287-aef23c28af0f@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <AuXXb5o9rZTaT3AfdQylxWiz2BypxLg3A8Fc_EtHlMg=.60edff4b-a874-48ea-b287-aef23c28af0f@github.com>
Message-ID: <zKwsQUh8B7dgfw-IeiO74X-Yboz9Fw4RAt-6UcNWfe8=.cf7681ed-708a-4ef2-adca-53a17516663b@github.com>

On Wed, 27 Oct 2021 08:12:05 GMT, Johan Vos <jvos at openjdk.org> wrote:

> This looks like a good solution, and I agree it fixes the issue. I have 2 minor concerns:
> 
> 1. Are we sure there are no platform-specific restrictions when using a `+` in a filename?
> 2. Testing this is probably difficult. We can only test it if a build is created (and the versionInfo is set).
> 
> I think the second concern can not be handled by our current test battery, but we do some smoke tests before releasing the maven repository, which should be able to detect this. If you are confident about the first concern, I think we're all good on this.

I tested the change by manipulating the folder value in `NativeLibLoader` on multiple jfx versions. That worked well. Today I tested the '+' sign for folders on windows (nfts) and different formatted usb sticks (Tried FAT, FAT32, exFat), linux and mac. They all work. 

If we want to be really safe we can replace a + by - or something else, but not sure if really needed.

I agree it's hard to test. I also thought of writing a test but it's not really possible. The libraries are also loaded different (no cache directory is created).

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

PR: https://git.openjdk.java.net/jfx/pull/654

From nlisker at openjdk.java.net  Wed Oct 27 16:09:21 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 27 Oct 2021 16:09:21 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <GGKi4WX9HbVgPaumF9MWb39blKf1DN5_uTP7nmK2FF0=.4633df35-1b1b-457b-a04c-b020ce1bec6f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
 <GGKi4WX9HbVgPaumF9MWb39blKf1DN5_uTP7nmK2FF0=.4633df35-1b1b-457b-a04c-b020ce1bec6f@github.com>
Message-ID: <i-4qBRG7hhBRfErmZvto_mHq4nJ2UPxhWzJyNjyEsAc=.1145171b-19c6-4c12-b77c-41b7e2f749ec@github.com>

On Wed, 27 Oct 2021 15:58:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 790:
> 
>> 788:      * If the width or height of this {@code Window} have never been set by the
>> 789:      * application, setting the scene will cause this {@code Window} to take its
>> 790:      * width or height from that scene.  Resizing this window by end user does
> 
> Extra space before "Resizing"

`{@code Window}` for consistency

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

PR: https://git.openjdk.java.net/jfx/pull/650

From nlisker at openjdk.java.net  Wed Oct 27 16:09:20 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 27 Oct 2021 16:09:20 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
Message-ID: <GGKi4WX9HbVgPaumF9MWb39blKf1DN5_uTP7nmK2FF0=.4633df35-1b1b-457b-a04c-b020ce1bec6f@github.com>

On Tue, 26 Oct 2021 09:54:43 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Added a few more comments, otherwise looks fine.

modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 156:

> 154: 
> 155:     /**
> 156:      * Creates a {@code PopupWindow}.

The `PopupWIndow` class is abstract. Do we still keep this wording?

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 231:

> 229: 
> 230:     /**
> 231:      * Creates a {@code Window}.

This is also a constructor for subclasses to call.

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 787:

> 785:      * reference before the new one gains it. You may swap {@code Scene}s on
> 786:      * a {@code Window} at any time, even if it is an instance of {@code Stage}
> 787:      * and with {@link Stage#fullScreenProperty() fullScreen} set to true.

"true" should be in `{@code}`

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 788:

> 786:      * a {@code Window} at any time, even if it is an instance of {@code Stage}
> 787:      * and with {@link Stage#fullScreenProperty() fullScreen} set to true.
> 788:      * If the width or height of this {@code Window} have never been set by the

I would start a new paragraph here since it switches from talking about a scene to talking about sizes.

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 790:

> 788:      * If the width or height of this {@code Window} have never been set by the
> 789:      * application, setting the scene will cause this {@code Window} to take its
> 790:      * width or height from that scene.  Resizing this window by end user does

Extra space before "Resizing"

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 794:

> 792:      *
> 793:      * An {@link IllegalStateException} is thrown if this property is set
> 794:      * on a thread other than the JavaFX Application Thread.</p>

Shouldn't this be in a `@throws`?

modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 796:

> 794:      * on a thread other than the JavaFX Application Thread.</p>
> 795:      *
> 796:      * @defaultValue null

`{@code null}`

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

PR: https://git.openjdk.java.net/jfx/pull/650

From nlisker at openjdk.java.net  Wed Oct 27 16:37:29 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Wed, 27 Oct 2021 16:37:29 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v4]
In-Reply-To: <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>
Message-ID: <WSxn8xGeVnoZGodaHP4E6VROlGWQNeyR2z3tmYhB_Ws=.76016b2e-54da-4b6d-9831-d42a078a4a43@github.com>

On Tue, 26 Oct 2021 06:24:35 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

modules/javafx.controls/src/main/java/javafx/scene/control/CheckMenuItem.java line 89:

> 87:      **************************************************************************/
> 88:     /**
> 89:      * Constructs a default {@code CheckMenuItem}.

`Label` uses "Creates an empty label" for the default constructor because it has no text or graphic. Maybe it's more informative that way.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 180:

> 178:      * variable contains style properties and values and not the
> 179:      * selector portion of a style rule.
> 180:      * A value of {@code null} is implicitly converted to an empty {@code String}.

Maybe this line should be in a new line/paragraph.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 183:

> 181:      *
> 182:      * @return the {@code style} property
> 183:      * @defaultValue null

`{@code null}`

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 1133:

> 1131:          */
> 1132:         public CSSBridge() {
> 1133:         }

Looking at the [docs for 17](https://openjfx.io/javadoc/17/javafx.controls/javafx/scene/control/PopupControl.CSSBridge.html), the constructor there is `protected`, here it's `public`. Was this changed recently? If it's supposed to be `protected`, then the constructor is for subclasses.

modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualContainerBase.java line 67:

> 65: 
> 66:     /**
> 67:      * Constructs a {@code VirtualContainerBase}

The class is `abstract`, so possibly the constructor should be `protected`, and we might want to say "Constructor for subclasses" anyway.

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

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Thu Oct 28 07:23:53 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 28 Oct 2021 07:23:53 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v4]
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <eGE-GGkXGC8un5ZpPqGJI9-_wMpNWi3fsWHd5xTxvxw=.424ac961-29dc-4cf0-b9db-1956427cd71c@github.com>

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/650/files
  - new: https://git.openjdk.java.net/jfx/pull/650/files/e4d337c5..69b6a759

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=02-03

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jfx/pull/650.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/650/head:pull/650

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Thu Oct 28 07:23:58 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 28 Oct 2021 07:23:58 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v3]
In-Reply-To: <GGKi4WX9HbVgPaumF9MWb39blKf1DN5_uTP7nmK2FF0=.4633df35-1b1b-457b-a04c-b020ce1bec6f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <MbXIRgOeh2tjHcHbyVEeueWvphu-eu7Mj80HlPmvR3Q=.deed9275-01a2-483e-b382-ba0da2f1d510@github.com>
 <GGKi4WX9HbVgPaumF9MWb39blKf1DN5_uTP7nmK2FF0=.4633df35-1b1b-457b-a04c-b020ce1bec6f@github.com>
Message-ID: <ZoToEBqcVfjZxR3lAYVSysY8vXVuYWJTaYcRxcE20Nk=.04984d36-a79b-49a2-b413-1beeaa32326c@github.com>

On Wed, 27 Oct 2021 16:06:38 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

> Added a few more comments, otherwise looks fine.

Thanks for your detailed review.

> modules/javafx.graphics/src/main/java/javafx/stage/PopupWindow.java line 156:
> 
>> 154: 
>> 155:     /**
>> 156:      * Creates a {@code PopupWindow}.
> 
> The `PopupWIndow` class is abstract. Do we still keep this wording?

I have changed it to - "Constructor for subclasses to call." as in other cases.

> modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 794:
> 
>> 792:      *
>> 793:      * An {@link IllegalStateException} is thrown if this property is set
>> 794:      * on a thread other than the JavaFX Application Thread.</p>
> 
> Shouldn't this be in a `@throws`?

Yes, only javadoc for `setScene()` method should use `@throws`.
The description for the property does not (and should not) recognize a `@throws`, hence I have kept the original description intact.

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

PR: https://git.openjdk.java.net/jfx/pull/650

From nlisker at openjdk.java.net  Thu Oct 28 07:53:18 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Thu, 28 Oct 2021 07:53:18 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v4]
In-Reply-To: <eGE-GGkXGC8un5ZpPqGJI9-_wMpNWi3fsWHd5xTxvxw=.424ac961-29dc-4cf0-b9db-1956427cd71c@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <eGE-GGkXGC8un5ZpPqGJI9-_wMpNWi3fsWHd5xTxvxw=.424ac961-29dc-4cf0-b9db-1956427cd71c@github.com>
Message-ID: <RtOYf1a2Y229PLnLdrQuPa5hRREcZpXL0L7Sje6SG5o=.21753566-cd9f-4776-85ce-8dfb68f16d11@github.com>

On Thu, 28 Oct 2021 07:23:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

I didn't check the generated HTML pages, and in some cases I'm not familiar enough with the API to evaluate the correctness of the description, but I checked the doc comments by themselves and these look good.

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

Marked as reviewed by nlisker (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/650

From duke at openjdk.java.net  Thu Oct 28 13:50:40 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Thu, 28 Oct 2021 13:50:40 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v13]
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <hIgSW_869XFTmFa0KXpZgJ-u9jRZiXLVwJ5EytGWKRM=.c744ecf2-4a8f-4e4d-983f-8cb72c7e6867@github.com>

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:

  8255015: Copyright year and wrong spelling in comment corrected

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/531/files
  - new: https://git.openjdk.java.net/jfx/pull/531/files/1598c604..9c10d967

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=11-12

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jfx/pull/531.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531

PR: https://git.openjdk.java.net/jfx/pull/531

From duke at openjdk.java.net  Thu Oct 28 13:50:44 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Thu, 28 Oct 2021 13:50:44 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v12]
In-Reply-To: <Pw-FSpaWV0YZbhPwq9WAIWmV8sTHQLirL4kAS5J_AFw=.ddc79c71-ebee-4a4c-ba16-582c04309e21@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <rhLdrkMEd410JmJ750UmxFtRmO3fb0Zab7oexbEALa8=.30770907-cc95-4475-af39-64d9f79f2295@github.com>
 <Pw-FSpaWV0YZbhPwq9WAIWmV8sTHQLirL4kAS5J_AFw=.ddc79c71-ebee-4a4c-ba16-582c04309e21@github.com>
Message-ID: <G7jTy0LsASRVUcDVskMnQ2Ab5YRyc1EjzQtm8G0-cMk=.5a61324d-6c2f-438e-83b7-616d396c12d8@github.com>

On Wed, 27 Oct 2021 09:36:20 GMT, Ambarish Rapte <arapte at openjdk.org> wrote:

>> Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255015: testScene variable must be volatile and new line at the end of the file added
>
> tests/system/src/test/java/test/robot/test3d/PointLightIlluminationTest.java line 148:
> 
>> 146:      * Creates a new scene with a subscene which contains a perspective camera and a sphere
>> 147:      * Although this test class checks the pointlight illumination, there is no explicit pointlight
>> 148:      * in the scene. For the test, it is sufficient to use the default pointlight which is created
> 
> minor: Please include this small correction along with the copyright year change. 
> pointlight -> point light

Thanks for the review! I corrected the copyright year and the point light spelling.

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

PR: https://git.openjdk.java.net/jfx/pull/531

From aghaisas at openjdk.java.net  Thu Oct 28 14:27:52 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 28 Oct 2021 14:27:52 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v5]
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/646/files
  - new: https://git.openjdk.java.net/jfx/pull/646/files/b4d5dc4f..1ab36f72

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=646&range=03-04

  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jfx/pull/646.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/646/head:pull/646

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Thu Oct 28 14:27:59 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 28 Oct 2021 14:27:59 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v4]
In-Reply-To: <WSxn8xGeVnoZGodaHP4E6VROlGWQNeyR2z3tmYhB_Ws=.76016b2e-54da-4b6d-9831-d42a078a4a43@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <NsXC2x5vMWIPPiRrD0i-7ANSs0qlo5eSgTWlskZhm3Q=.e0158f58-dacb-46f6-9ac9-5fd7420d0546@github.com>
 <WSxn8xGeVnoZGodaHP4E6VROlGWQNeyR2z3tmYhB_Ws=.76016b2e-54da-4b6d-9831-d42a078a4a43@github.com>
Message-ID: <Svf6fcfretQWo4nfHweBSeXPZYp_JHNGQUvHieE8yzg=.19e9afe8-802a-403d-80be-701f32c90ff2@github.com>

On Wed, 27 Oct 2021 16:12:11 GMT, Nir Lisker <nlisker at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/CheckMenuItem.java line 89:
> 
>> 87:      **************************************************************************/
>> 88:     /**
>> 89:      * Constructs a default {@code CheckMenuItem}.
> 
> `Label` uses "Creates an empty label" for the default constructor because it has no text or graphic. Maybe it's more informative that way.

It does make sense to modify it. I will change it.

> modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 1133:
> 
>> 1131:          */
>> 1132:         public CSSBridge() {
>> 1133:         }
> 
> Looking at the [docs for 17](https://openjfx.io/javadoc/17/javafx.controls/javafx/scene/control/PopupControl.CSSBridge.html), the constructor there is `protected`, here it's `public`. Was this changed recently? If it's supposed to be `protected`, then the constructor is for subclasses.

This is a very good catch. Thanks!

Changing this to public was a mistake this PR was about to make.
In openjfx17, there is no constructor defined - that means - it gets generated implicitly which is `protected`.
I introduced an explicit constructor in this PR while fixing the "missing javadoc" comment. Inadvertently I had made it `public` in this PR.
Now, I have made it `protected` in the latest commit.

> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualContainerBase.java line 67:
> 
>> 65: 
>> 66:     /**
>> 67:      * Constructs a {@code VirtualContainerBase}
> 
> The class is `abstract`, so possibly the constructor should be `protected`, and we might want to say "Constructor for subclasses" anyway.

I have corrected the javadoc to match "Constructor for subclasses to call.".
I would like to avoid changing the access modifier to `protected` as part of javadoc fix.

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

PR: https://git.openjdk.java.net/jfx/pull/646

From michaelstrau2 at gmail.com  Thu Oct 28 16:51:25 2021
From: michaelstrau2 at gmail.com (=?UTF-8?Q?Michael_Strau=C3=9F?=)
Date: Thu, 28 Oct 2021 18:51:25 +0200
Subject: Improve property system to facilitate correct usage
In-Reply-To: <CAJEpuXQSjS2wDD=2GAmtZMBKus1u01e-vWJo+3KutFd1Y+yfMw@mail.gmail.com>
References: <CAJEpuXQSjS2wDD=2GAmtZMBKus1u01e-vWJo+3KutFd1Y+yfMw@mail.gmail.com>
Message-ID: <CAJEpuXRWcveyfYab3qbN2hUiaeorchyG4HgW0qLT8=Urb74TUw@mail.gmail.com>

I'd like to discuss the API changes surrounding content bindings for
this PR: https://github.com/openjdk/jfx/pull/590

Content bindings in the property system are semantically similar to
regular bindings:
1. You can only have a single content binding for a collection-type property
2. Unidirectional content bindings and bidirectional content bindings
are mutually exclusive

For this reason, and in order to support the behavioral changes
outlined in the PR, the content binding API (in ReadOnlyListProperty)
was changed as follows:

    void bindContent(ObservableList<E> source);
  + @Deprecated(since = "18", forRemoval = true)
    void unbindContent(Object object);
  + void unbindContent();
  + boolean isContentBound();

This is not a breaking change, and allows application developers to
phase out the superfluous argument for `unbindContent` over time.

What might be more controversial is that this imposes a new
implementation requirement for some exotic implementations of
collection-type properties:

1. Right now, content bindings are implemented in
ReadOnlyListProperty, and every implementation of ROLP inherits the
default content binding implementation.

2. With the changed API, the implementation moves from
ReadOnlyListProperty to (ReadOnly)ListPropertyBase. This means that a
class that implements (RO)LP, but not (RO)LPBase, does not inherit the
default content binding implementation and needs to provide its own
implementation if it wants to support content bindings.

Of course, implementing (RO)LP without using (RO)LPBase is extremely
unusual. It requires the implementer to re-implement lots of code like
`ListExpressionHelper` and binding listeners.
Still, it's an additional requirement for these implementations that
also want to support content bindings. If content bindings are not
required, then the "old" (RO)LP implementation will continue to
compile and work.

What we get from this change are powerful correctness guarantees for
users of the API. Do you think this is a trade worth making?


On Wed, Jul 28, 2021 at 1:23 AM Michael Strau? <michaelstrau2 at gmail.com> wrote:
>
> I propose a set of changes to the JavaFX property system that I've
> outlined in this PR: https://github.com/openjdk/jfx/pull/590
>
> The changes fall into two categories: enforcement of correct usage
> (there are several cases listed in the PR), and deprecating untyped
> APIs (for removal in a future version) so as to make the intent of the
> API more clear to developers.
>
> Even though there are breaking changes, the impact on application code
> should be minimal. I'd welcome any comments on this proposal.

From jhendrikx at openjdk.java.net  Thu Oct 28 20:40:22 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Thu, 28 Oct 2021 20:40:22 GMT
Subject: RFR: 8274274: Update JUnit to version 5.8.1 [v5]
In-Reply-To: <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
References: <rucQpoQckz65kU-gd1XWyNifMwzjSTOz197mwwEKTFQ=.189d92da-7491-42e0-8934-8a62904d6828@github.com>
 <numXoypAtOjjaKk5n0Xzz457FXiO12sQaleYC7RQ6sQ=.308ec53f-d307-4e58-aeec-a480ac893fc7@github.com>
Message-ID: <sqWaY-EQG2UpNO8t9MqtWMkQ_XOEV1IuZ9QrDIfJVTo=.f80f6cb9-ff99-437d-9efc-8d9e096a39a7@github.com>

On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests still work.  Also added a single JUnit 5 tests, and confirmed it works.
>> 
>> I've updated the Eclipse project file for the base module only.
>
> John Hendrikx has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Readd junit declaration in allprojects and set junit version to 4.13.2

I was on holidays, I've updated the title.

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

PR: https://git.openjdk.java.net/jfx/pull/633

From kcr at openjdk.java.net  Thu Oct 28 23:37:20 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 Oct 2021 23:37:20 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v5]
In-Reply-To: <aGSxjJRP-mMMHZIPxApeUAtattWeNQemr9qFcsOLsFI=.efc9b158-fc20-487c-88b6-af0a711a7645@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
 <aGSxjJRP-mMMHZIPxApeUAtattWeNQemr9qFcsOLsFI=.efc9b158-fc20-487c-88b6-af0a711a7645@github.com>
Message-ID: <qc8lqJqRwxu3BuI-qAzWZjXpITCPeX6hcggvcLYAmBY=.3dfe0934-987a-4b85-af64-813c0adfdafa@github.com>

On Thu, 28 Oct 2021 23:30:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix review comments
>
> modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 1132:
> 
>> 1130:          * Constructor for subclasses to call.
>> 1131:          */
>> 1132:         protected CSSBridge() {
> 
> Please revert this change. Since the class is protected, it's a compatible change, but any change to a method's signature, return type, or modifiers needs a CSR.

Oh! never mind. I misread this. I see that you _are_ reverting it back. That's good then (and a good catch).

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

PR: https://git.openjdk.java.net/jfx/pull/646

From kcr at openjdk.java.net  Thu Oct 28 23:37:19 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 Oct 2021 23:37:19 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v5]
In-Reply-To: <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
Message-ID: <aGSxjJRP-mMMHZIPxApeUAtattWeNQemr9qFcsOLsFI=.efc9b158-fc20-487c-88b6-af0a711a7645@github.com>

On Thu, 28 Oct 2021 14:27:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

The doc changes look good. Please revert the access modifier change.

modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java line 1132:

> 1130:          * Constructor for subclasses to call.
> 1131:          */
> 1132:         protected CSSBridge() {

Please revert this change. Since the class is protected, it's a compatible change, but any change to a method's signature, return type, or modifiers needs a CSR.

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

Changes requested by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/646

From kcr at openjdk.java.net  Thu Oct 28 23:43:18 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 Oct 2021 23:43:18 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v13]
In-Reply-To: <hIgSW_869XFTmFa0KXpZgJ-u9jRZiXLVwJ5EytGWKRM=.c744ecf2-4a8f-4e4d-983f-8cb72c7e6867@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <hIgSW_869XFTmFa0KXpZgJ-u9jRZiXLVwJ5EytGWKRM=.c744ecf2-4a8f-4e4d-983f-8cb72c7e6867@github.com>
Message-ID: <y6Vd7T0pMdY-2I2i6YYWiOy2mt_ouDHlimoj29feckw=.b1a2e1d2-4f66-47d1-9d25-0bf8860630de@github.com>

On Thu, 28 Oct 2021 13:50:40 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

>> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
>> 
>> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)
>
> Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255015: Copyright year and wrong spelling in comment corrected

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/531

From kcr at openjdk.java.net  Thu Oct 28 23:53:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 Oct 2021 23:53:16 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v5]
In-Reply-To: <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
Message-ID: <Zj_cZsuZgTj7A-fuLoC8S19MWfRoZ7-d3PCGzABWwwo=.1519a089-9f4d-4ac2-a958-dd0ba15fb86b@github.com>

On Thu, 28 Oct 2021 14:27:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

This looks good. I confirmed that the implicit constructor for `PopupControl.CSSBridge` is `protected` in JavaFX 17, so making the explicitly added contructor be `protected` is correct.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/646

From kcr at openjdk.java.net  Thu Oct 28 23:57:16 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 28 Oct 2021 23:57:16 GMT
Subject: RFR: 8271090: Missing API docs in scenegraph classes [v4]
In-Reply-To: <eGE-GGkXGC8un5ZpPqGJI9-_wMpNWi3fsWHd5xTxvxw=.424ac961-29dc-4cf0-b9db-1956427cd71c@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
 <eGE-GGkXGC8un5ZpPqGJI9-_wMpNWi3fsWHd5xTxvxw=.424ac961-29dc-4cf0-b9db-1956427cd71c@github.com>
Message-ID: <FNNBTdL0smZ2_MUvAGrado0Bm4tSJ4-mrQjhUgNP1Us=.924ef60f-4946-4261-b441-228cee07c60b@github.com>

On Thu, 28 Oct 2021 07:23:53 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>> 
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/650

From nlisker at openjdk.java.net  Fri Oct 29 02:15:13 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 29 Oct 2021 02:15:13 GMT
Subject: RFR: 8271091: Missing API docs in UI controls classes [v5]
In-Reply-To: <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
 <FKq31_iYJktT65ti3UXS0sVjJSu4kNjHicomW3OhTDs=.9ad2ce6b-42a6-47f2-828c-9c752d8eb25e@github.com>
Message-ID: <z7CyENVhXVUE9aO__AQ7MCy4k15iWm9oK562iNclzHI=.bf348e87-14d5-4c93-90dc-5af8a6f364e7@github.com>

On Thu, 28 Oct 2021 14:27:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note : 
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
>> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix review comments

I didn't check the generated HTML pages or the correctness of the docs with respect to the functionality of their methods, but the docs themselves look good.

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

Marked as reviewed by nlisker (Reviewer).

PR: https://git.openjdk.java.net/jfx/pull/646

From aghaisas at openjdk.java.net  Fri Oct 29 04:20:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 04:20:16 GMT
Subject: Integrated: 8271090: Missing API docs in scenegraph classes
In-Reply-To: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
References: <qe6tYJpC-NF42QI7vcMJY6nnJN2xi8bYkccxRCjdrwM=.3df253f1-8977-4f0f-a5af-5ec41ac6e60f@github.com>
Message-ID: <oFB8W8YRRtdhpCfuBrRtrN9Xj9AbTWKqd8q99_wHb7w=.6bd51e36-ab0f-4e7e-9f16-14dd69ae0f6f@github.com>

On Fri, 22 Oct 2021 11:23:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes javadoc warnings primarily in javafx.graphics module along with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
> 
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

This pull request has now been integrated.

Changeset: e7a106fa
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/e7a106faf3c0bb0126080d2f516248195679bf61
Stats:     133 lines in 28 files changed: 89 ins; 4 del; 40 mod

8271090: Missing API docs in scenegraph classes

Reviewed-by: kcr, nlisker

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

PR: https://git.openjdk.java.net/jfx/pull/650

From aghaisas at openjdk.java.net  Fri Oct 29 04:25:14 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 04:25:14 GMT
Subject: Integrated: 8271091: Missing API docs in UI controls classes
In-Reply-To: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
References: <XdSNGHirHkG9www0ardsf-j_JxZn5XLI4bqIBtsMlU0=.5e50849b-cf06-4876-b246-7f0a5833a071@github.com>
Message-ID: <XRTQP68xXTbgORy1d5LXLiFxgo4nZDRFRx_KKzTD_a8=.63bf63f4-f95a-4780-97c3-8e5c8068b283@github.com>

On Wed, 20 Oct 2021 14:42:44 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note : 
> - The javadoc needs to be generated with the JDK 18 EA build.
> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under - [JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085)
> - There are still 20 javadoc warnings remaining in javafx.controls module and 3 warnings remaining in javafx.web module. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)

This pull request has now been integrated.

Changeset: a9474055
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/a9474055994d104288aff22fdb70f76ed8519627
Stats:     269 lines in 49 files changed: 147 ins; 15 del; 107 mod

8271091: Missing API docs in UI controls classes

Reviewed-by: nlisker, kcr

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

PR: https://git.openjdk.java.net/jfx/pull/646

From arapte at openjdk.java.net  Fri Oct 29 06:06:28 2021
From: arapte at openjdk.java.net (Ambarish Rapte)
Date: Fri, 29 Oct 2021 06:06:28 GMT
Subject: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight
 [v13]
In-Reply-To: <hIgSW_869XFTmFa0KXpZgJ-u9jRZiXLVwJ5EytGWKRM=.c744ecf2-4a8f-4e4d-983f-8cb72c7e6867@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
 <hIgSW_869XFTmFa0KXpZgJ-u9jRZiXLVwJ5EytGWKRM=.c744ecf2-4a8f-4e4d-983f-8cb72c7e6867@github.com>
Message-ID: <lbYtlG43r0-4ZoclhCYf_OJ0veW1aAD3FiXjIdBhaRE=.e3a64604-d4d3-4de5-8f37-1a4b65df5cf5@github.com>

On Thu, 28 Oct 2021 13:50:40 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

>> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
>> 
>> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)
>
> Andreas Heger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255015: Copyright year and wrong spelling in comment corrected

Marked as reviewed by arapte (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/531

From aghaisas at openjdk.java.net  Fri Oct 29 07:37:31 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 07:37:31 GMT
Subject: RFR: 8275848: Deprecate mistakenly exposed field from class
 javafx.scene.shape.Box
Message-ID: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>

This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.

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

Commit messages:
 - Deprecate DEFAULT_SIZE constant field

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

PR: https://git.openjdk.java.net/jfx/pull/655

From aghaisas at openjdk.java.net  Fri Oct 29 10:19:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 10:19:16 GMT
Subject: RFR: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit [v3]
In-Reply-To: <6Yizd_tITIxMk8FQyqNQEsLQButJKy3MTQGro0ax1N4=.ec406d6e-05fc-4d00-86a0-0c01db1e9d6e@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
 <6Yizd_tITIxMk8FQyqNQEsLQButJKy3MTQGro0ax1N4=.ec406d6e-05fc-4d00-86a0-0c01db1e9d6e@github.com>
Message-ID: <IfdHV6AAdzVmcfztVBc5UeQHO8nZGDh65gOuJWmsRHI=.b5d87ea7-f563-4992-a646-a1773d2f91e6@github.com>

On Fri, 22 Oct 2021 10:36:24 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
>> 
>> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
>> 
>> Added/unignored cell tests that are failing/passing before/after the fix.
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   next try with fixing the formatting

Marked as reviewed by aghaisas (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/638

From fkirmaier at openjdk.java.net  Fri Oct 29 10:57:16 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 29 Oct 2021 10:57:16 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v7]
In-Reply-To: <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
Message-ID: <9JOyZeeBrVhRLqYdJL0R7FD4rqzdW8UHSblqKKPjzv8=.7c1b48fd-405a-4c68-9ad9-c4b250a6442a@github.com>

On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   Fixing toggle fullscreen!

#### not a real regression
I think I've hunted a regression, which was none. When closing the application with `System.exit` the screen gets red, but this isn't caused by my change.
I've even got a fix for it, but it requires changing the lifecycle slightly, by closing all windows on shutdown. (And some other minor changes to fix some exceptions)

        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            System.out.println("tkExit shutdown hook!");
            PlatformImpl.tkExit();
        }));

But because this isn't caused by my changes, we can therefore ignore it. But I had to mention it because I invested too much time into it.


#### toggle
I've readded the toggle code. It's worth mentioning that the code is different than before.

The original version caused a "beep sound" when closing the window `[self->nativeFullScreenModeWindow performSelector:@selector(toggleFullScreen:) withObject:nil];`

The new version doesn't have this problem - but it's also fixing the problem from the previous version. `[[self->nsView window] toggleFullScreen:self];`

#### exception
With the current version, I also cannot reproduce the problem, with the exception.

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

PR: https://git.openjdk.java.net/jfx/pull/622

From fkirmaier at openjdk.java.net  Fri Oct 29 11:10:17 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 29 Oct 2021 11:10:17 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: <F57dNR7mFD8WeoTsoWzXHLCX6uvNn1zt8x2mH-css-o=.003e7871-1c35-47cd-9871-5e51d3033e5e@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <GwUj4mH4dnEFsVR8e77nUsErRBCdrgRfFBU_TGKyQ1c=.73ca840a-1b70-4219-81cc-7d7c1b761301@github.com>
 <F57dNR7mFD8WeoTsoWzXHLCX6uvNn1zt8x2mH-css-o=.003e7871-1c35-47cd-9871-5e51d3033e5e@github.com>
Message-ID: <QTDtUlcLVwocyEHp9QaVjtjoKMKsZOvcVzGM8E9Nqw0=.e8be1d73-d836-401a-8f7a-391225ce6bc2@github.com>

On Thu, 14 Oct 2021 14:29:55 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8269907
>>   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.
>
> I don't have a good suggestion at the moment.
> 
> Converting this to Draft, since it isn't (yet) ready for review.

@kevinrushforth 
Can we rediscuss whether this version of the fix is ok?

I think the fix is technically fine. 
Adding a "runLater" like api to the PulseListener should also be fine, and might be useful for other problems too.
The fix is also already used in production - for the latest [JPro](https://jpro.one/) version and for desktop applications. Therefore I'm very confident, that this fix doesn't cause any problems.

This fix is also very important for large desktop applications. In context with Popups, the bug can cause unpredictable memory leaks.

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

PR: https://git.openjdk.java.net/jfx/pull/584

From aghaisas at openjdk.java.net  Fri Oct 29 11:27:14 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 11:27:14 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working
In-Reply-To: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
Message-ID: <thdplbY1SXSRcaGhx2BJqRMlzRV8a7WsaOUAcQX6k_4=.b2cc7b2e-3598-4fe0-9048-9db471ae0ef0@github.com>

On Wed, 20 Oct 2021 16:54:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 238:

> 236:         }
> 237: 
> 238:         return !isExtendedMnemonic(s, position);

I am not sure why do we need to check for isExtendedMnemonic() inside isSimpleMnemonic() implementation.
These two methods should be separate and it is up to the callers to check and take appropriate action.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From kcr at openjdk.java.net  Fri Oct 29 11:33:12 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 11:33:12 GMT
Subject: RFR: 8275848: Deprecate mistakenly exposed field from class
 javafx.scene.shape.Box
In-Reply-To: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
References: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
Message-ID: <EydApuNF3AwU8XWyYkuZ9q34ETxg5LOVi0yYzo6Z3X0=.a2396000-aced-43c2-8a57-b1d227788a7f@github.com>

On Fri, 29 Oct 2021 07:31:05 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.

This looks good with one minor comment. Please also change the title of the JBS issues (both the bug and the CSR) and this PR to add "for removal" after "Deprecate". So maybe:


Deprecate for removal mistakenly exposed field from javafx.scene.shape.Box

modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 90:

> 88:     /**
> 89:      * Default size of the {@code Box}.
> 90:      * @deprecated This field was exposed mistakenly and will be removed

Can you add a period at the end?

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

PR: https://git.openjdk.java.net/jfx/pull/655

From kcr at openjdk.java.net  Fri Oct 29 11:37:12 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 11:37:12 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v7]
In-Reply-To: <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
Message-ID: <7Z0uyNY7_x3yeq_tfE3ZtrgQHl4-0RuDhj3KnSRxStg=.855b364f-38d6-458d-adb2-9a5dba5fe432@github.com>

On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   Fixing toggle fullscreen!

I still see the exception described in [this comment](#issuecomment-943406855) when the application calls `Platform.exit()` while in full screen. I am running on macOS 10.15.7. I'll try it on macOS 11.x as well.

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

PR: https://git.openjdk.java.net/jfx/pull/622

From aghaisas at openjdk.java.net  Fri Oct 29 11:42:38 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 11:42:38 GMT
Subject: RFR: 8275848: Deprecate for removal mistakenly exposed field from
 class javafx.scene.shape.Box [v2]
In-Reply-To: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
References: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
Message-ID: <h94G9ylCQe7YzkLh7Mg0G3tyTTXmz8RrX8UB2_dljAQ=.b6d06e59-de7b-4ad0-be0b-40e542bf9c1a@github.com>

> This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  review fix

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/655/files
  - new: https://git.openjdk.java.net/jfx/pull/655/files/d5021e2d..6305fde5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=655&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=655&range=00-01

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

PR: https://git.openjdk.java.net/jfx/pull/655

From kcr at openjdk.java.net  Fri Oct 29 12:15:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 12:15:09 GMT
Subject: RFR: 8275848: Deprecate for removal mistakenly exposed field from
 class javafx.scene.shape.Box [v2]
In-Reply-To: <h94G9ylCQe7YzkLh7Mg0G3tyTTXmz8RrX8UB2_dljAQ=.b6d06e59-de7b-4ad0-be0b-40e542bf9c1a@github.com>
References: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
 <h94G9ylCQe7YzkLh7Mg0G3tyTTXmz8RrX8UB2_dljAQ=.b6d06e59-de7b-4ad0-be0b-40e542bf9c1a@github.com>
Message-ID: <WvbeVQrSMoO-VLyAClSG6YExX5KCkLSI_BPDh1XcCq4=.879cd470-9cfb-4159-a782-03e506d0c90d@github.com>

On Fri, 29 Oct 2021 11:42:38 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

Looks good.

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

Marked as reviewed by kcr (Lead).

PR: https://git.openjdk.java.net/jfx/pull/655

From nlisker at openjdk.java.net  Fri Oct 29 12:20:14 2021
From: nlisker at openjdk.java.net (Nir Lisker)
Date: Fri, 29 Oct 2021 12:20:14 GMT
Subject: RFR: 8275848: Deprecate for removal mistakenly exposed field from
 class javafx.scene.shape.Box [v2]
In-Reply-To: <h94G9ylCQe7YzkLh7Mg0G3tyTTXmz8RrX8UB2_dljAQ=.b6d06e59-de7b-4ad0-be0b-40e542bf9c1a@github.com>
References: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
 <h94G9ylCQe7YzkLh7Mg0G3tyTTXmz8RrX8UB2_dljAQ=.b6d06e59-de7b-4ad0-be0b-40e542bf9c1a@github.com>
Message-ID: <pf2ol5txkEIS_k-2N3k16dzieP_oKeRLFRd5ZdU78DQ=.a6a7176b-0980-4e71-bc00-8e79a02d4b0b@github.com>

On Fri, 29 Oct 2021 11:42:38 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review fix

Marked as reviewed by nlisker (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/655

From mstrauss at openjdk.java.net  Fri Oct 29 12:25:51 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 12:25:51 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v2]
In-Reply-To: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
Message-ID: <RcSYwl2Y6cWpY1ZHpS8_MJx4DnKPtyEFx-uPCQQm5ec=.222b4d18-aebc-46f6-acec-2fa080c60a54@github.com>

> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  Removed isExtendedMnemonic check from isSimpleMnemonic

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/647/files
  - new: https://git.openjdk.java.net/jfx/pull/647/files/7cc78d4a..af670b07

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=00-01

  Stats: 18 lines in 1 file changed: 5 ins; 9 del; 4 mod
  Patch: https://git.openjdk.java.net/jfx/pull/647.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/647/head:pull/647

PR: https://git.openjdk.java.net/jfx/pull/647

From fastegal at openjdk.java.net  Fri Oct 29 12:32:15 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Fri, 29 Oct 2021 12:32:15 GMT
Subject: Integrated: 8187474: Tree-/TableCell,
 TreeCell: editingCell/Item not updated in cell.startEdit
In-Reply-To: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
References: <Zn0XahIcDuj0tDpqTQz9hPs7hH49igh2KGsAS9BDI8s=.637cf761-3434-4288-8bd5-f8946fe0f8b0@github.com>
Message-ID: <5Mvqx5ctIHq8QMBFrTHc8mmopjQPwYA5jSe1gPvwJfU=.3dd11c55-f988-47bc-a745-85c3ceb9ee8b@github.com>

On Tue, 5 Oct 2021 13:18:07 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> cell startEdit is supposed to update the editing location on its associated control - was done in ListCell, not in Tree-/TableCell nor TreeCell.
> 
> Fix was to add control.edit(..). Note that ListCell was also touched to use the exact same method call pattern as the fixed cell types.
> 
> Added/unignored cell tests that are failing/passing before/after the fix.

This pull request has now been integrated.

Changeset: adcc40d5
Author:    Jeanette Winzenburg <fastegal at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/adcc40d57c0f2619cad0ca5ffc2ed9e9a5e032b0
Stats:     77 lines in 7 files changed: 46 ins; 22 del; 9 mod

8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit

Reviewed-by: mhanl, aghaisas

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

PR: https://git.openjdk.java.net/jfx/pull/638

From mstrauss at openjdk.java.net  Fri Oct 29 12:38:17 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 12:38:17 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v2]
In-Reply-To: <thdplbY1SXSRcaGhx2BJqRMlzRV8a7WsaOUAcQX6k_4=.b2cc7b2e-3598-4fe0-9048-9db471ae0ef0@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <thdplbY1SXSRcaGhx2BJqRMlzRV8a7WsaOUAcQX6k_4=.b2cc7b2e-3598-4fe0-9048-9db471ae0ef0@github.com>
Message-ID: <ao787_8zdWpctLSXtCxiQ0fht-Qjyoq2uxP_Rd3sgW8=.bf82e5f8-e34c-4dea-b965-80eb4a2e4aec@github.com>

On Fri, 29 Oct 2021 11:23:50 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed isExtendedMnemonic check from isSimpleMnemonic
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 238:
> 
>> 236:         }
>> 237: 
>> 238:         return !isExtendedMnemonic(s, position);
> 
> I am not sure why do we need to check for isExtendedMnemonic() inside isSimpleMnemonic() implementation.
> These two methods should be separate and it is up to the callers to check and take appropriate action.

Done.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From aghaisas at openjdk.java.net  Fri Oct 29 13:48:19 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 13:48:19 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v2]
In-Reply-To: <ao787_8zdWpctLSXtCxiQ0fht-Qjyoq2uxP_Rd3sgW8=.bf82e5f8-e34c-4dea-b965-80eb4a2e4aec@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <thdplbY1SXSRcaGhx2BJqRMlzRV8a7WsaOUAcQX6k_4=.b2cc7b2e-3598-4fe0-9048-9db471ae0ef0@github.com>
 <ao787_8zdWpctLSXtCxiQ0fht-Qjyoq2uxP_Rd3sgW8=.bf82e5f8-e34c-4dea-b965-80eb4a2e4aec@github.com>
Message-ID: <LkBIJy1X0Fqxno4aBtHH1-Iv8HYwFyzfUvnth4WD5I4=.34c4c5f3-c1b4-4bcc-84ee-21e10760d143@github.com>

On Fri, 29 Oct 2021 12:34:50 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 238:
>> 
>>> 236:         }
>>> 237: 
>>> 238:         return !isExtendedMnemonic(s, position);
>> 
>> I am not sure why do we need to check for isExtendedMnemonic() inside isSimpleMnemonic() implementation.
>> These two methods should be separate and it is up to the callers to check and take appropriate action.
>
> Done.

The corresponding comment for the method isSimpleMnemonic() also needs correction.
You can limit it to -

    /**
     * Determines whether the string contains a simple mnemonic at the specified position.
     * A simple mnemonic is any two-character string similar to "_x", where x is not an
     * underscore or a whitespace character.
     */

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

PR: https://git.openjdk.java.net/jfx/pull/647

From mstrauss at openjdk.java.net  Fri Oct 29 13:58:35 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 13:58:35 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
Message-ID: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>

> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.

Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:

  changed javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/647/files
  - new: https://git.openjdk.java.net/jfx/pull/647/files/af670b07..c4012056

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/647.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/647/head:pull/647

PR: https://git.openjdk.java.net/jfx/pull/647

From mstrauss at openjdk.java.net  Fri Oct 29 13:58:36 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 13:58:36 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <LkBIJy1X0Fqxno4aBtHH1-Iv8HYwFyzfUvnth4WD5I4=.34c4c5f3-c1b4-4bcc-84ee-21e10760d143@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <thdplbY1SXSRcaGhx2BJqRMlzRV8a7WsaOUAcQX6k_4=.b2cc7b2e-3598-4fe0-9048-9db471ae0ef0@github.com>
 <ao787_8zdWpctLSXtCxiQ0fht-Qjyoq2uxP_Rd3sgW8=.bf82e5f8-e34c-4dea-b965-80eb4a2e4aec@github.com>
 <LkBIJy1X0Fqxno4aBtHH1-Iv8HYwFyzfUvnth4WD5I4=.34c4c5f3-c1b4-4bcc-84ee-21e10760d143@github.com>
Message-ID: <rxacfJHfNhe4wP7evcbjc70MmhPLxI48V_EMNma8KIs=.82678cbc-7d9d-4fa9-a873-4f646635b538@github.com>

On Fri, 29 Oct 2021 13:45:24 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> Done.
>
> The corresponding comment for the method isSimpleMnemonic() also needs correction.
> You can limit it to -
> 
>     /**
>      * Determines whether the string contains a simple mnemonic at the specified position.
>      * A simple mnemonic is any two-character string similar to "_x", where x is not an
>      * underscore or a whitespace character.
>      */

Done.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From duke at openjdk.java.net  Fri Oct 29 14:14:25 2021
From: duke at openjdk.java.net (Andreas Heger)
Date: Fri, 29 Oct 2021 14:14:25 GMT
Subject: Integrated: 8255015: Inconsistent illumination of 3D shape by
 PointLight
In-Reply-To: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
References: <UCFTGSp1xnEd18qxsG4YActQ5jUGBt70-MDRhD1IBE0=.10118241-a374-4529-aeb1-4ea666a4c363@github.com>
Message-ID: <01TR8QNYFGrU2AJVLp5dgurxXOQjGcybGr1H_PwDSSo=.25adfc8e-250d-428b-a542-aad82f68800e@github.com>

On Wed, 9 Jun 2021 18:22:31 GMT, Andreas Heger <duke at openjdk.java.net> wrote:

> The inconsistent illumination happens on Macs with retina displays only if the 3D shape is placed in a SubScene. The light sources are located with wrong coordinates in sub scenes and this causes a different illumination. The wrong coordinates for the light sources come from the fact that the retina pixel scale factors are not used in a SubScene.
> 
> With this pull request, the retina pixel scale factors will be also used in SubScenes and this should resolve the bug [https://bugs.openjdk.java.net/browse/JDK-8255015](url)

This pull request has now been integrated.

Changeset: 161e434b
Author:    andreas-heger <heger at gmx.de>
Committer: Nir Lisker <nlisker at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/161e434b1238d657f95e5ffcd3749027e066ca76
Stats:     184 lines in 2 files changed: 184 ins; 0 del; 0 mod

8255015: Inconsistent illumination of 3D shape by PointLight

Reviewed-by: kcr, arapte

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

PR: https://git.openjdk.java.net/jfx/pull/531

From aghaisas at openjdk.java.net  Fri Oct 29 14:22:16 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 14:22:16 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
Message-ID: <QPnNxA4mWZCXHQSLSDaYvmUj560Hb6Ly2HPl1Qrzbqc=.40ba97b9-2aef-467e-a16f-f915871bfff8@github.com>

On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed javadoc

Marked as reviewed by aghaisas (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/647

From aghaisas at openjdk.java.net  Fri Oct 29 14:25:15 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 29 Oct 2021 14:25:15 GMT
Subject: Integrated: 8275848: Deprecate for removal mistakenly exposed field
 from class javafx.scene.shape.Box
In-Reply-To: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
References: <MGSkQ4sgH3cz33C5rqTuQDzzFj3zkCp_iMmvtus4QiY=.29db5cf3-e58c-4edd-82c2-33f8d076b3ac@github.com>
Message-ID: <BqtQiKNNC4JOqssPyxMXcQfgAJpEM6jjfpgKw0gV-Ug=.3352ba52-260f-4357-8568-ac7c0be66a1a@github.com>

On Fri, 29 Oct 2021 07:31:05 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> This PR deprecates mistakenly exposed field from class javafx.scene.shape.Box.

This pull request has now been integrated.

Changeset: d9e1ad97
Author:    Ajit Ghaisas <aghaisas at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/d9e1ad976873799128871c0544f6eb26e843b880
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8275848: Deprecate for removal mistakenly exposed field from class javafx.scene.shape.Box

Reviewed-by: kcr, nlisker

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

PR: https://git.openjdk.java.net/jfx/pull/655

From mstrauss at openjdk.java.net  Fri Oct 29 14:34:15 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 14:34:15 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <VYFFPqmnPVwfLhLQHVSXhFAJB71eZ295rRVMuGAF4BQ=.c62653ff-6282-47e9-b2bc-8ff3e97b9bcd@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

Perhaps it would also be a good idea to move these files to the user's temporary directory, so that they can be cleaned up by the system. Otherwise they probably won't be removed in most cases when the user removes the application that created them.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From mstrauss at openjdk.java.net  Fri Oct 29 14:37:14 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 14:37:14 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS [v2]
In-Reply-To: <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
 <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
Message-ID: <ouQNWai8g-qF3NfLbAmlNQcIGFuC7lLWje9kzRjc1m8=.001f2020-b0d3-420b-956f-7af9b8983dd7@github.com>

On Thu, 14 Oct 2021 21:47:16 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

>> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
>> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
>> 
>> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
>> https://bugs.openjdk.java.net/browse/JDK-8268657
>> It also looks different so I don't think this PR fixes this, if it is still there.
>
> Marius Hanl has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8274699: Revert whitespace
>  - 8274699: Revert minor code change

Looks good, although the solution in itself remains fishy. Maybe create a ticket to implement a better solution in the future?

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

Marked as reviewed by mstrauss (Author).

PR: https://git.openjdk.java.net/jfx/pull/640

From fkirmaier at openjdk.java.net  Fri Oct 29 15:16:25 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 29 Oct 2021 15:16:25 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
Message-ID: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>

removing dead code.
When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

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

Commit messages:
 - JDK-8276179

Changes: https://git.openjdk.java.net/jfx/pull/658/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=658&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8276179
  Stats: 34 lines in 2 files changed: 0 ins; 34 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/658.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/658/head:pull/658

PR: https://git.openjdk.java.net/jfx/pull/658

From kcr at openjdk.java.net  Fri Oct 29 15:23:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 15:23:14 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <80Nxqn6zJtuWe2mJd-IvczBlk2JjjJasAg5TW0aX5qI=.795e3ce3-1eaa-45a9-985e-e68af757de6a@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

A quick look suggests that this is, in fact, unused. I would like Phil to review it, though.

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

PR: https://git.openjdk.java.net/jfx/pull/658

From fkirmaier at openjdk.java.net  Fri Oct 29 15:31:17 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 29 Oct 2021 15:31:17 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v7]
In-Reply-To: <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
Message-ID: <lhQ_unigF18KfSmSVJShSqvfepzVFOK1Oy1ZQ5n5iOc=.e96a2158-e465-4d33-bf14-e7df6cf0805f@github.com>

On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   Fixing toggle fullscreen!

I will also recheck for the Exception. I've seen it multiple times, especially when investigating the "red screen", but   I haven't seen it with the latest version. But maybe I'm testing it now somehow differently.

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

PR: https://git.openjdk.java.net/jfx/pull/622

From fkirmaier at openjdk.java.net  Fri Oct 29 15:40:15 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Fri, 29 Oct 2021 15:40:15 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <OV5MdB8K39nHecuNNs4iCaAxxN3DFe0GY1HXGZFDzMU=.cf18ae6c-5dff-4af3-8e9b-56ae3b2d40eb@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

I've also seen many places in the font code, which just catch Exceptions without handling them, nor logging them.
This is really frightening when investigating issues with fonts. 
It seems like some Exceptions are expected, but it's not known which Exceptions are expected. No wonder the font-loading features often feel unstable.

Should I also make a PR for this problem?

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

PR: https://git.openjdk.java.net/jfx/pull/658

From mhanl at openjdk.java.net  Fri Oct 29 15:41:11 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 29 Oct 2021 15:41:11 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS [v2]
In-Reply-To: <ouQNWai8g-qF3NfLbAmlNQcIGFuC7lLWje9kzRjc1m8=.001f2020-b0d3-420b-956f-7af9b8983dd7@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
 <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
 <ouQNWai8g-qF3NfLbAmlNQcIGFuC7lLWje9kzRjc1m8=.001f2020-b0d3-420b-956f-7af9b8983dd7@github.com>
Message-ID: <1mMY9Tg-s0hqfH5MuElrbgJeep7XfW9YZwQQ8m7Kqww=.9a09deaa-9272-42ef-b6a4-5a5ad6cd7a79@github.com>

On Fri, 29 Oct 2021 14:34:39 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Looks good, although the solution in itself remains fishy. Maybe create a ticket to implement a better solution in the future?

yes, the css code is sometimes very ... interesting. I didn't had a deep look but it's weird that there are converters - which converts the value while its also done here. A cleanup generally is not a bad idea here. That's also visible by the amount of TODOs in the code.

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

PR: https://git.openjdk.java.net/jfx/pull/640

From mhanl at openjdk.java.net  Fri Oct 29 15:41:12 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Fri, 29 Oct 2021 15:41:12 GMT
Subject: Integrated: 8274699: Certain blend modes cannot be set from CSS
In-Reply-To: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
Message-ID: <HYXnaQKKRtsQBJ6ycwBO8fQFzkhpBLk3WK1UkhKbg4k=.280f82d4-291d-4d0c-83b8-0ef8bd27ba3a@github.com>

On Wed, 6 Oct 2021 07:43:15 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This PR fixes a bug where the blend mode will be falsely recognized as a color and therefore won't be set. 
> Also a ClassCastException is thrown (The converter expects a String, but gets a Color).
> 
> Note: There is another similar bug but I can't reproduce it (Tried with 18-ea+3).
> https://bugs.openjdk.java.net/browse/JDK-8268657
> It also looks different so I don't think this PR fixes this, if it is still there.

This pull request has now been integrated.

Changeset: c6f4ff01
Author:    Marius Hanl <mhanl at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/c6f4ff01f2af7d2616b0b49a51ded3ec69f7b0a5
Stats:     13 lines in 2 files changed: 9 ins; 1 del; 3 mod

8274699: Certain blend modes cannot be set from CSS

Reviewed-by: kcr, mstrauss

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

PR: https://git.openjdk.java.net/jfx/pull/640

From kcr at openjdk.java.net  Fri Oct 29 15:53:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 15:53:14 GMT
Subject: RFR: 8274699: Certain blend modes cannot be set from CSS [v2]
In-Reply-To: <1mMY9Tg-s0hqfH5MuElrbgJeep7XfW9YZwQQ8m7Kqww=.9a09deaa-9272-42ef-b6a4-5a5ad6cd7a79@github.com>
References: <SKqsV3N96R53Of1XNUxN_wM0Uswa4cBbpthyJc7HsSY=.2030cd71-04ee-40d0-b65e-fad32e6e9de6@github.com>
 <Bbam8gvTtxXEnrifsCheyHRz4-vlj2Tr3FbNzORjOT4=.66a311ca-3389-488e-96db-0c2a21a33fd0@github.com>
 <ouQNWai8g-qF3NfLbAmlNQcIGFuC7lLWje9kzRjc1m8=.001f2020-b0d3-420b-956f-7af9b8983dd7@github.com>
 <1mMY9Tg-s0hqfH5MuElrbgJeep7XfW9YZwQQ8m7Kqww=.9a09deaa-9272-42ef-b6a4-5a5ad6cd7a79@github.com>
Message-ID: <LngoPHLweiTomw6TRtDNxWOCwIUQXPN_2OV9kAGmT-I=.94f90cb5-fe10-460a-acf1-7734d7339c9e@github.com>

On Fri, 29 Oct 2021 15:37:36 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> > Looks good, although the solution in itself remains fishy. Maybe create a ticket to implement a better solution in the future?
> 
> yes, the css code is sometimes very ... interesting. I have not looked closely but it's weird that there are converters - which converts the value while its also done here. A cleanup generally is not a bad idea here. That's also visible by the amount of TODOs in the code.

I filed [JDK-8276180](https://bugs.openjdk.java.net/browse/JDK-8276180) to track this particular cleanup.

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

PR: https://git.openjdk.java.net/jfx/pull/640

From prr at openjdk.java.net  Fri Oct 29 17:19:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 17:19:11 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <9aj62X5QGDwZP7CRyYbWTuyZxcPkYlddF46cyolfux4=.e47f7958-09b3-4fb6-ac9a-b5a51d424cd1@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/658

From swpalmer at gmail.com  Fri Oct 29 17:53:46 2021
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 29 Oct 2021 13:53:46 -0400
Subject: Mnemonic Parsing doesn't appear to work properly
Message-ID: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>

I looked in the bug database and while there are lots of bugs reported
against the mnemonic parsing, they claim to be fixed.

After noticing something peculiar on a control in my app (it was showing a
file path and I hadn't disabled the mnemonic parsing) I did some tests.

The documentation is unclear on what should happen if multiple underscores
are in the text.  It just says if the mnemonic parsing character '_'
appears that the key combination will be based on the succeeding
character.  I presume that it should pick only ONE of the underscores and
subsequent character, either the first or the last would make sense.
However, the behavior is that an unrelated character is shown as the
mnemonic and even it doesn't actually do anything.  Tested with JDK 17.0.1
and JavaFX 17.0.1.

Does this behave as expected for you?


package mnemonic_parsing_bug;

import javafx.application.Application;
import javafx.geometry.Insets;
import javafx.scene.Scene;
import javafx.scene.control.CheckBox;
import javafx.scene.control.Label;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class Main extends Application {

    public static void main(String[] args) {
        launch(args);
    }

    @Override
    public void start(Stage primaryStage) throws Exception {
        Label titleLabel = new Label("""
            The CheckBox below has text set to 'How_to_Test_Mnemonics'.
            On Windows press the Alt key to see where the underlined
character appears.
            It shows under the 'e' in Mnemonics for me, and I can't figure
out
            what key combination (if any) actually does something.
            [JavaFX Version %s]""".formatted(System.getProperty(
"javafx.version")) );
        titleLabel.setMnemonicParsing(false);
        CheckBox mnemonicCB = new CheckBox("How_to_Test_Mnemonics");
        mnemonicCB.setMnemonicParsing(true);
        VBox box = new VBox(8,titleLabel, mnemonicCB);
        box.setPadding(new Insets(16));
        Scene scene = new Scene(box);
        primaryStage.setTitle("Mnemonic Parsing Bug");
        primaryStage.setScene(scene);
        primaryStage.show();
    }

}

From prr at openjdk.java.net  Fri Oct 29 19:24:11 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 29 Oct 2021 19:24:11 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <6gflt3ZPCf0wBOC-nM5Eod54rXyTAJWk35VBCby4aKg=.4655498a-8d8b-430b-bbb7-cec2085f7974@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

Marked as reviewed by prr (Reviewer).

I'm quite confident the build will be a good test of whether it is unused so fine by me.
I am a little curious as to when it stopped being used and why .. but that isn't a blocker.

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

PR: https://git.openjdk.java.net/jfx/pull/658

From hjohn at xs4all.nl  Fri Oct 29 19:45:04 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Fri, 29 Oct 2021 21:45:04 +0200
Subject: Mnemonic Parsing doesn't appear to work properly
In-Reply-To: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>
References: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>
Message-ID: <995c1ea8-86d7-64b1-423d-03749b9cceec@xs4all.nl>

Hm, I can confirm it appears under the "e", also under Windows, but I 
suspect the platform will make no difference.

I tested a bit further, and I found the following:

1) The mnemonic key seems to be "m", and it appears under the "e" 
because it deleted two more underscores (index is off by 2). What makes 
this hard to discover however is my second finding:

2) Checkbox doesn't toggle at all when you use the correct mnemonic, a 
Button however works.

3) If you add an "onAction" to the Checkbox that prints something on the 
console, you can see the mnemonic working, but the Checkbox is still not 
toggled.

I checked the mnemonic parsing code, and if you run it in isolation, it 
finds the first underscore and has the correct index 
(TextBinding#parseAndSplit). I stopped there, but perhaps the code 
actually runs for each underscore found (it updates the text, perhaps 
this triggers another parsing run).

--John

On 29/10/2021 19:53, Scott Palmer wrote:
> I looked in the bug database and while there are lots of bugs reported
> against the mnemonic parsing, they claim to be fixed.
>
> After noticing something peculiar on a control in my app (it was showing a
> file path and I hadn't disabled the mnemonic parsing) I did some tests.
>
> The documentation is unclear on what should happen if multiple underscores
> are in the text.  It just says if the mnemonic parsing character '_'
> appears that the key combination will be based on the succeeding
> character.  I presume that it should pick only ONE of the underscores and
> subsequent character, either the first or the last would make sense.
> However, the behavior is that an unrelated character is shown as the
> mnemonic and even it doesn't actually do anything.  Tested with JDK 17.0.1
> and JavaFX 17.0.1.
>
> Does this behave as expected for you?
>
>
> package mnemonic_parsing_bug;
>
> import javafx.application.Application;
> import javafx.geometry.Insets;
> import javafx.scene.Scene;
> import javafx.scene.control.CheckBox;
> import javafx.scene.control.Label;
> import javafx.scene.layout.VBox;
> import javafx.stage.Stage;
>
> public class Main extends Application {
>
>     public static void main(String[] args) {
>         launch(args);
>     }
>
>     @Override
>     public void start(Stage primaryStage) throws Exception {
>         Label titleLabel = new Label("""
>             The CheckBox below has text set to 'How_to_Test_Mnemonics'.
>             On Windows press the Alt key to see where the underlined
> character appears.
>             It shows under the 'e' in Mnemonics for me, and I can't figure
> out
>             what key combination (if any) actually does something.
>             [JavaFX Version %s]""".formatted(System.getProperty(
> "javafx.version")) );
>         titleLabel.setMnemonicParsing(false);
>         CheckBox mnemonicCB = new CheckBox("How_to_Test_Mnemonics");
>         mnemonicCB.setMnemonicParsing(true);
>         VBox box = new VBox(8,titleLabel, mnemonicCB);
>         box.setPadding(new Insets(16));
>         Scene scene = new Scene(box);
>         primaryStage.setTitle("Mnemonic Parsing Bug");
>         primaryStage.setScene(scene);
>         primaryStage.show();
>     }
>
> }
>

From hjohn at xs4all.nl  Fri Oct 29 20:12:16 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Fri, 29 Oct 2021 22:12:16 +0200
Subject: Mnemonic Parsing doesn't appear to work properly
In-Reply-To: <995c1ea8-86d7-64b1-423d-03749b9cceec@xs4all.nl>
References: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>
 <995c1ea8-86d7-64b1-423d-03749b9cceec@xs4all.nl>
Message-ID: <bd34ac82-5928-89af-0287-25364c6d8a6c@xs4all.nl>

Looking a bit further, and I noticed this code has recently been 
rewritten. The old code used StringBuffer and wasn't that easy to read, 
but the new code although easier to read seems to contain several 
changes in how things used to work.

The most noticable is that it doesn't stop after it finds the first 
mnemonic (probably because it is now building a new string and stopping 
half way would result in an incomplete string -- the old code instead 
would delete parts from a copy so it could stop early, although that has 
some bugs too I noticed).

The new code therefore finds the last mnemonic instead of the first, but 
unfortunately, there is an off by one error that becomes gradually worse 
as more underscores are encountered.

Compare the outputs (Input: How_to_test_mnemonics):

Old version 
(https://github.com/openjdk/jfx/blob/jfx16/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java):
=========================

Resulting Label = Howto_test_mnemonics; mnemonicIndex = 3; mnemonic = t

Current version (master):
=========================

Resulting Label = Howtotestmnemonics; mnemonicIndex = 11; mnemonic = m

It looks like a significant change in how things used to work which the 
tests didn't catch at all.

--John

On 29/10/2021 21:45, John Hendrikx wrote:
> Hm, I can confirm it appears under the "e", also under Windows, but I
> suspect the platform will make no difference.
>
> I tested a bit further, and I found the following:
>
> 1) The mnemonic key seems to be "m", and it appears under the "e"
> because it deleted two more underscores (index is off by 2). What makes
> this hard to discover however is my second finding:
>
> 2) Checkbox doesn't toggle at all when you use the correct mnemonic, a
> Button however works.
>
> 3) If you add an "onAction" to the Checkbox that prints something on the
> console, you can see the mnemonic working, but the Checkbox is still not
> toggled.
>
> I checked the mnemonic parsing code, and if you run it in isolation, it
> finds the first underscore and has the correct index
> (TextBinding#parseAndSplit). I stopped there, but perhaps the code
> actually runs for each underscore found (it updates the text, perhaps
> this triggers another parsing run).
>
> --John
>
> On 29/10/2021 19:53, Scott Palmer wrote:
>> I looked in the bug database and while there are lots of bugs reported
>> against the mnemonic parsing, they claim to be fixed.
>>
>> After noticing something peculiar on a control in my app (it was
>> showing a
>> file path and I hadn't disabled the mnemonic parsing) I did some tests.
>>
>> The documentation is unclear on what should happen if multiple
>> underscores
>> are in the text.  It just says if the mnemonic parsing character '_'
>> appears that the key combination will be based on the succeeding
>> character.  I presume that it should pick only ONE of the underscores and
>> subsequent character, either the first or the last would make sense.
>> However, the behavior is that an unrelated character is shown as the
>> mnemonic and even it doesn't actually do anything.  Tested with JDK
>> 17.0.1
>> and JavaFX 17.0.1.
>>
>> Does this behave as expected for you?
>>
>>
>> package mnemonic_parsing_bug;
>>
>> import javafx.application.Application;
>> import javafx.geometry.Insets;
>> import javafx.scene.Scene;
>> import javafx.scene.control.CheckBox;
>> import javafx.scene.control.Label;
>> import javafx.scene.layout.VBox;
>> import javafx.stage.Stage;
>>
>> public class Main extends Application {
>>
>>     public static void main(String[] args) {
>>         launch(args);
>>     }
>>
>>     @Override
>>     public void start(Stage primaryStage) throws Exception {
>>         Label titleLabel = new Label("""
>>             The CheckBox below has text set to 'How_to_Test_Mnemonics'.
>>             On Windows press the Alt key to see where the underlined
>> character appears.
>>             It shows under the 'e' in Mnemonics for me, and I can't
>> figure
>> out
>>             what key combination (if any) actually does something.
>>             [JavaFX Version %s]""".formatted(System.getProperty(
>> "javafx.version")) );
>>         titleLabel.setMnemonicParsing(false);
>>         CheckBox mnemonicCB = new CheckBox("How_to_Test_Mnemonics");
>>         mnemonicCB.setMnemonicParsing(true);
>>         VBox box = new VBox(8,titleLabel, mnemonicCB);
>>         box.setPadding(new Insets(16));
>>         Scene scene = new Scene(box);
>>         primaryStage.setTitle("Mnemonic Parsing Bug");
>>         primaryStage.setScene(scene);
>>         primaryStage.show();
>>     }
>>
>> }
>>
>

From jhendrikx at openjdk.java.net  Fri Oct 29 20:22:13 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Fri, 29 Oct 2021 20:22:13 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
Message-ID: <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>

On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed javadoc

modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2162:

> 2160:         label.autosize();
> 2161:         skin.updateDisplayedText();
> 2162:         assertEquals("foo _bar _qux", LabelSkinBaseShim.getText(label).getText());

Can you verify here which letter / index is picked as mnemonic? (Also in the other tests).

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jhendrikx at openjdk.java.net  Fri Oct 29 20:30:15 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Fri, 29 Oct 2021 20:30:15 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
Message-ID: <bIltMhs5TCiZd1zz5HwGmxV9RCWUMwb6c8wO36KQQY8=.fd0353b5-f256-41fc-955c-64fe2305749a@github.com>

On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed javadoc

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 188:

> 186:         int i = 0;
> 187: 
> 188:         // Parse the input string and stop after the first mnemonic.

This seems to do much more than just fixing numeric mnemonics.  Now it stops after the first mnemonic, whereas it picked the last mnemonic before this change (which seems to be a regression from what happened in jfx16).

I think the regression should be fixed first, then additional features can be added?

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

PR: https://git.openjdk.java.net/jfx/pull/647

From mstrauss at openjdk.java.net  Fri Oct 29 20:57:16 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 20:57:16 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <bIltMhs5TCiZd1zz5HwGmxV9RCWUMwb6c8wO36KQQY8=.fd0353b5-f256-41fc-955c-64fe2305749a@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <bIltMhs5TCiZd1zz5HwGmxV9RCWUMwb6c8wO36KQQY8=.fd0353b5-f256-41fc-955c-64fe2305749a@github.com>
Message-ID: <L73UMDAyqNXeNBX1mbYTXPmzxMH9dGLUhK1LtJBnt50=.071c4db9-abcd-441e-8355-6a2ccf0d327a@github.com>

On Fri, 29 Oct 2021 20:26:56 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed javadoc
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 188:
> 
>> 186:         int i = 0;
>> 187: 
>> 188:         // Parse the input string and stop after the first mnemonic.
> 
> This seems to do much more than just fixing numeric mnemonics.  Now it stops after the first mnemonic, whereas it picked the last mnemonic before this change (which seems to be a regression from what happened in jfx16).
> 
> I think the regression should be fixed first, then additional features can be added?

This PR does not add any additional feature. It restores the behavior of jfx16, where any character is acceptable as a mnemonic, and the first mnemonic is selected.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From tsayao at openjdk.java.net  Fri Oct 29 21:35:46 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Fri, 29 Oct 2021 21:35:46 GMT
Subject: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage
 creation [v4]
In-Reply-To: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
Message-ID: <-3sjgh02t13IenDbA39DUM_Qbnauw-4oRJg3udFVO9A=.3fd4a51c-9c2b-4b75-aacb-5330f55d1962@github.com>

> Found the problem thru this path:
> 
> **WindowStage.java**
> 
>     final void handleFocusDisabled() {
>         if (activeWindows.isEmpty()) {
>             return;
>         }
>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>         window.setIconified(false);
>         window.requestToFront();
>         window.requestFocus();
>     }
> 
> 
> **glass_window.cpp**
> 
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>    ...
> 
>     if (jwindow) {
>         if (!event->in || isEnabled()) {
>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>             CHECK_JNI_EXCEPTION(mainEnv)
>         } else {
>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>             CHECK_JNI_EXCEPTION(mainEnv)
>         }
>     }
> }
> 
> 
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
> 
> The docs states:
> 
>     /**
>      * Enables or disables the window.
>      *
>      * A disabled window is unfocusable by definition.
>      * Also, key or mouse events aren't generated for disabled windows.
>      *
>      * When a user tries to activate a disabled window, or the window gets
>      * accidentally brought to the top of the stacking order, the window
>      * generates the FOCUS_DISABLED window event. A Glass client should react
>      * to this event and bring the currently active modal blocker of the
>      * disabled window to top by calling blocker's minimize(false), toFront(),
>      * and requestFocus() methods. It may also 'blink' the blocker window to
>      * further attract user's attention.
>      *
>      .....
> 
> 
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
> 
> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.

Thiago Milczarek Sayao has updated the pull request 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:

 - Prevent focus stealing
 - Merge branch 'master' into jdk_8271054_wrong_stage_gets_focused_after_modal_stage_creation
 - Merge branch 'openjdk:master' into master
 - Break if reach self
 - handleFocusDisabled() should bring up the blocker window not the previous one.
 - Fix for JDK-8271054
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge pull request #18 from openjdk/master
   
   Merge master
 - Merge pull request #17 from openjdk/master
   
   Pull from origin
 - ... and 13 more: https://git.openjdk.java.net/jfx/compare/fa234fdd...eca324df

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/598/files
  - new: https://git.openjdk.java.net/jfx/pull/598/files/eb93b8b9..eca324df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=02-03

  Stats: 9848 lines in 801 files changed: 8688 ins; 160 del; 1000 mod
  Patch: https://git.openjdk.java.net/jfx/pull/598.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598

PR: https://git.openjdk.java.net/jfx/pull/598

From hjohn at xs4all.nl  Fri Oct 29 22:20:57 2021
From: hjohn at xs4all.nl (John Hendrikx)
Date: Sat, 30 Oct 2021 00:20:57 +0200
Subject: Mnemonic Parsing doesn't appear to work properly
In-Reply-To: <bd34ac82-5928-89af-0287-25364c6d8a6c@xs4all.nl>
References: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>
 <995c1ea8-86d7-64b1-423d-03749b9cceec@xs4all.nl>
 <bd34ac82-5928-89af-0287-25364c6d8a6c@xs4all.nl>
Message-ID: <bcf5df27-0115-686c-7c1d-3976d1b8955b@xs4all.nl>

The fix is in progress here: https://github.com/openjdk/jfx/pull/647

On 29/10/2021 22:12, John Hendrikx wrote:
> Looking a bit further, and I noticed this code has recently been
> rewritten. The old code used StringBuffer and wasn't that easy to read,
> but the new code although easier to read seems to contain several
> changes in how things used to work.
>
> The most noticable is that it doesn't stop after it finds the first
> mnemonic (probably because it is now building a new string and stopping
> half way would result in an incomplete string -- the old code instead
> would delete parts from a copy so it could stop early, although that has
> some bugs too I noticed).
>
> The new code therefore finds the last mnemonic instead of the first, but
> unfortunately, there is an off by one error that becomes gradually worse
> as more underscores are encountered.
>
> Compare the outputs (Input: How_to_test_mnemonics):
>
> Old version
> (https://github.com/openjdk/jfx/blob/jfx16/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java):
>
> =========================
>
> Resulting Label = Howto_test_mnemonics; mnemonicIndex = 3; mnemonic = t
>
> Current version (master):
> =========================
>
> Resulting Label = Howtotestmnemonics; mnemonicIndex = 11; mnemonic = m
>
> It looks like a significant change in how things used to work which the
> tests didn't catch at all.
>
> --John
>
> On 29/10/2021 21:45, John Hendrikx wrote:
>> Hm, I can confirm it appears under the "e", also under Windows, but I
>> suspect the platform will make no difference.
>>
>> I tested a bit further, and I found the following:
>>
>> 1) The mnemonic key seems to be "m", and it appears under the "e"
>> because it deleted two more underscores (index is off by 2). What makes
>> this hard to discover however is my second finding:
>>
>> 2) Checkbox doesn't toggle at all when you use the correct mnemonic, a
>> Button however works.
>>
>> 3) If you add an "onAction" to the Checkbox that prints something on the
>> console, you can see the mnemonic working, but the Checkbox is still not
>> toggled.
>>
>> I checked the mnemonic parsing code, and if you run it in isolation, it
>> finds the first underscore and has the correct index
>> (TextBinding#parseAndSplit). I stopped there, but perhaps the code
>> actually runs for each underscore found (it updates the text, perhaps
>> this triggers another parsing run).
>>
>> --John
>>
>> On 29/10/2021 19:53, Scott Palmer wrote:
>>> I looked in the bug database and while there are lots of bugs reported
>>> against the mnemonic parsing, they claim to be fixed.
>>>
>>> After noticing something peculiar on a control in my app (it was
>>> showing a
>>> file path and I hadn't disabled the mnemonic parsing) I did some tests.
>>>
>>> The documentation is unclear on what should happen if multiple
>>> underscores
>>> are in the text.  It just says if the mnemonic parsing character '_'
>>> appears that the key combination will be based on the succeeding
>>> character.  I presume that it should pick only ONE of the underscores
>>> and
>>> subsequent character, either the first or the last would make sense.
>>> However, the behavior is that an unrelated character is shown as the
>>> mnemonic and even it doesn't actually do anything.  Tested with JDK
>>> 17.0.1
>>> and JavaFX 17.0.1.
>>>
>>> Does this behave as expected for you?
>>>
>>>
>>> package mnemonic_parsing_bug;
>>>
>>> import javafx.application.Application;
>>> import javafx.geometry.Insets;
>>> import javafx.scene.Scene;
>>> import javafx.scene.control.CheckBox;
>>> import javafx.scene.control.Label;
>>> import javafx.scene.layout.VBox;
>>> import javafx.stage.Stage;
>>>
>>> public class Main extends Application {
>>>
>>>     public static void main(String[] args) {
>>>         launch(args);
>>>     }
>>>
>>>     @Override
>>>     public void start(Stage primaryStage) throws Exception {
>>>         Label titleLabel = new Label("""
>>>             The CheckBox below has text set to 'How_to_Test_Mnemonics'.
>>>             On Windows press the Alt key to see where the underlined
>>> character appears.
>>>             It shows under the 'e' in Mnemonics for me, and I can't
>>> figure
>>> out
>>>             what key combination (if any) actually does something.
>>>             [JavaFX Version %s]""".formatted(System.getProperty(
>>> "javafx.version")) );
>>>         titleLabel.setMnemonicParsing(false);
>>>         CheckBox mnemonicCB = new CheckBox("How_to_Test_Mnemonics");
>>>         mnemonicCB.setMnemonicParsing(true);
>>>         VBox box = new VBox(8,titleLabel, mnemonicCB);
>>>         box.setPadding(new Insets(16));
>>>         Scene scene = new Scene(box);
>>>         primaryStage.setTitle("Mnemonic Parsing Bug");
>>>         primaryStage.setScene(scene);
>>>         primaryStage.show();
>>>     }
>>>
>>> }
>>>
>>
>

From jhendrikx at openjdk.java.net  Fri Oct 29 22:22:11 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Fri, 29 Oct 2021 22:22:11 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <L73UMDAyqNXeNBX1mbYTXPmzxMH9dGLUhK1LtJBnt50=.071c4db9-abcd-441e-8355-6a2ccf0d327a@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <bIltMhs5TCiZd1zz5HwGmxV9RCWUMwb6c8wO36KQQY8=.fd0353b5-f256-41fc-955c-64fe2305749a@github.com>
 <L73UMDAyqNXeNBX1mbYTXPmzxMH9dGLUhK1LtJBnt50=.071c4db9-abcd-441e-8355-6a2ccf0d327a@github.com>
Message-ID: <P3WNpZRREapG18Dv_6qC1ixdbb8iblhzqNZ9CAj6x28=.9e04b9c5-9085-4abb-acbc-2ce5a3bb610b@github.com>

On Fri, 29 Oct 2021 20:54:04 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java line 188:
>> 
>>> 186:         int i = 0;
>>> 187: 
>>> 188:         // Parse the input string and stop after the first mnemonic.
>> 
>> This seems to do much more than just fixing numeric mnemonics.  Now it stops after the first mnemonic, whereas it picked the last mnemonic before this change (which seems to be a regression from what happened in jfx16).
>> 
>> I think the regression should be fixed first, then additional features can be added?
>
> This PR does not add any additional feature. It restores the behavior of jfx16, where any character is acceptable as a mnemonic, and the first mnemonic is selected.

Okay, the wording of the JBS ticket suggested something else, but I see it is just a regression fix.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From tsayao at openjdk.java.net  Fri Oct 29 22:35:47 2021
From: tsayao at openjdk.java.net (Thiago Milczarek Sayao)
Date: Fri, 29 Oct 2021 22:35:47 GMT
Subject: RFR: WIP: 8271054: [REDO] Wrong stage gets focused after modal
 stage creation [v5]
In-Reply-To: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
References: <JgBw-c7fLesSALPhbiy2uRj-O5CeLJVtScp7empsvA0=.5407d9d4-b94c-437d-b1d9-041c23930172@github.com>
Message-ID: <KOpAVPsoKjrl2XspgyN7vJhUw222M6YIHcVXloxpGqk=.db881698-b324-492d-a66e-cbfcb691f684@github.com>

> Found the problem thru this path:
> 
> **WindowStage.java**
> 
>     final void handleFocusDisabled() {
>         if (activeWindows.isEmpty()) {
>             return;
>         }
>         WindowStage window = activeWindows.get(activeWindows.size() - 1);
>         window.setIconified(false);
>         window.requestToFront();
>         window.requestFocus();
>     }
> 
> 
> **glass_window.cpp**
> 
> void WindowContextBase::process_focus(GdkEventFocus* event) {
>    ...
> 
>     if (jwindow) {
>         if (!event->in || isEnabled()) {
>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocus,
>                     event->in ? com_sun_glass_events_WindowEvent_FOCUS_GAINED : com_sun_glass_events_WindowEvent_FOCUS_LOST);
>             CHECK_JNI_EXCEPTION(mainEnv)
>         } else {
>             mainEnv->CallVoidMethod(jwindow, jWindowNotifyFocusDisabled);
>             CHECK_JNI_EXCEPTION(mainEnv)
>         }
>     }
> }
> 
> 
> So `glass_window.cpp` was triggering `jWindowNotifyFocusDisabled` which triggered the java code on the Primary Stage (on the bug reproduce code).
> 
> The docs states:
> 
>     /**
>      * Enables or disables the window.
>      *
>      * A disabled window is unfocusable by definition.
>      * Also, key or mouse events aren't generated for disabled windows.
>      *
>      * When a user tries to activate a disabled window, or the window gets
>      * accidentally brought to the top of the stacking order, the window
>      * generates the FOCUS_DISABLED window event. A Glass client should react
>      * to this event and bring the currently active modal blocker of the
>      * disabled window to top by calling blocker's minimize(false), toFront(),
>      * and requestFocus() methods. It may also 'blink' the blocker window to
>      * further attract user's attention.
>      *
>      .....
> 
> 
> So I guess the C++ side looks ok, java side on `handleFocusDisabled` I did not understand why it `requestToFront` and `requestFocus` on the latest window.
> 
> The solution makes disabled windows unfocusable and prevents mouse and keyboard events as the docs states, making it compatible with other platforms.

Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:

  Still not correct

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/598/files
  - new: https://git.openjdk.java.net/jfx/pull/598/files/eca324df..c54a5413

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=598&range=03-04

  Stats: 18 lines in 5 files changed: 3 ins; 6 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/598.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/598/head:pull/598

PR: https://git.openjdk.java.net/jfx/pull/598

From mstrauss at openjdk.java.net  Fri Oct 29 23:17:15 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Fri, 29 Oct 2021 23:17:15 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>
Message-ID: <4TBn3vRqwk0VEaD8Tn6S_45G-cyQGg5fEz4TuJbKpo4=.4cb01871-bd90-468c-9471-c22a75e5bfd6@github.com>

On Fri, 29 Oct 2021 20:19:02 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed javadoc
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2162:
> 
>> 2160:         label.autosize();
>> 2161:         skin.updateDisplayedText();
>> 2162:         assertEquals("foo _bar _qux", LabelSkinBaseShim.getText(label).getText());
> 
> Can you verify here which letter / index is picked as mnemonic? (Also in the other tests).

I don't see an easy way to do that, and I'm not in favor of making private implementation details package-public just to test some internal state. Of course, mnemonic support should have been designed in a way that is more easily testable, but this PR is not the place to do that.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From kcr at openjdk.java.net  Fri Oct 29 23:49:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 23:49:13 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <0G1Ex8eH8ZE9y6vJn6vtzPGqayaO3HhCoVt-yQhnw9I=.9a9ab637-bc94-4283-b8ab-199c492b3b7f@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/658

From kcr at openjdk.java.net  Fri Oct 29 23:49:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 29 Oct 2021 23:49:13 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <OV5MdB8K39nHecuNNs4iCaAxxN3DFe0GY1HXGZFDzMU=.cf18ae6c-5dff-4af3-8e9b-56ae3b2d40eb@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
 <OV5MdB8K39nHecuNNs4iCaAxxN3DFe0GY1HXGZFDzMU=.cf18ae6c-5dff-4af3-8e9b-56ae3b2d40eb@github.com>
Message-ID: <wieamq1XE6WlM259XTr6C9nvcLvAk-RgEdi3jfR2jbg=.d4120f18-11e9-4f91-bc4c-c5a40c8a0b76@github.com>

On Fri, 29 Oct 2021 15:37:24 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> I've also seen many places in the font code, which just catch Exceptions without handling them, nor logging them. This is really frightening when investigating issues with fonts. It seems like some Exceptions are expected, but it's not known which Exceptions are expected. No wonder the font-loading features often feel unstable.

You can file a new bug if you like. As long as we don't start getting noise from exceptions that don't matter, it seems a good idea to log them when they happen.

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

PR: https://git.openjdk.java.net/jfx/pull/658

From swpalmer at gmail.com  Sat Oct 30 01:31:22 2021
From: swpalmer at gmail.com (Scott Palmer)
Date: Fri, 29 Oct 2021 21:31:22 -0400
Subject: Mnemonic Parsing doesn't appear to work properly
In-Reply-To: <bcf5df27-0115-686c-7c1d-3976d1b8955b@xs4all.nl>
References: <CAL3e5iFRyKrf56v_R+6Y2GJ7Z6Uaec7LOfFW1xA8OdvU9Ecjuw@mail.gmail.com>
 <995c1ea8-86d7-64b1-423d-03749b9cceec@xs4all.nl>
 <bd34ac82-5928-89af-0287-25364c6d8a6c@xs4all.nl>
 <bcf5df27-0115-686c-7c1d-3976d1b8955b@xs4all.nl>
Message-ID: <E3569509-544C-4C53-8E9D-55FA66E4F8FC@gmail.com>

Ah, great.
It would be nice to see progress on  JDK-8088370 <https://bugs.openjdk.java.net/browse/JDK-8088370> (it?s been 6 years since it was reported) for the mnemonic not toggling a checkbox.

Scott

> On Oct 29, 2021, at 6:20 PM, John Hendrikx <hjohn at xs4all.nl> wrote:
> 
> The fix is in progress here: https://github.com/openjdk/jfx/pull/647
> 
> On 29/10/2021 22:12, John Hendrikx wrote:
>> Looking a bit further, and I noticed this code has recently been
>> rewritten. The old code used StringBuffer and wasn't that easy to read,
>> but the new code although easier to read seems to contain several
>> changes in how things used to work.
>> 
>> The most noticable is that it doesn't stop after it finds the first
>> mnemonic (probably because it is now building a new string and stopping
>> half way would result in an incomplete string -- the old code instead
>> would delete parts from a copy so it could stop early, although that has
>> some bugs too I noticed).
>> 
>> The new code therefore finds the last mnemonic instead of the first, but
>> unfortunately, there is an off by one error that becomes gradually worse
>> as more underscores are encountered.
>> 
>> Compare the outputs (Input: How_to_test_mnemonics):
>> 
>> Old version
>> (https://github.com/openjdk/jfx/blob/jfx16/modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/TextBinding.java):
>> 
>> =========================
>> 
>> Resulting Label = Howto_test_mnemonics; mnemonicIndex = 3; mnemonic = t
>> 
>> Current version (master):
>> =========================
>> 
>> Resulting Label = Howtotestmnemonics; mnemonicIndex = 11; mnemonic = m
>> 
>> It looks like a significant change in how things used to work which the
>> tests didn't catch at all.
>> 
>> --John
>> 
>> On 29/10/2021 21:45, John Hendrikx wrote:
>>> Hm, I can confirm it appears under the "e", also under Windows, but I
>>> suspect the platform will make no difference.
>>> 
>>> I tested a bit further, and I found the following:
>>> 
>>> 1) The mnemonic key seems to be "m", and it appears under the "e"
>>> because it deleted two more underscores (index is off by 2). What makes
>>> this hard to discover however is my second finding:
>>> 
>>> 2) Checkbox doesn't toggle at all when you use the correct mnemonic, a
>>> Button however works.
>>> 
>>> 3) If you add an "onAction" to the Checkbox that prints something on the
>>> console, you can see the mnemonic working, but the Checkbox is still not
>>> toggled.
>>> 
>>> I checked the mnemonic parsing code, and if you run it in isolation, it
>>> finds the first underscore and has the correct index
>>> (TextBinding#parseAndSplit). I stopped there, but perhaps the code
>>> actually runs for each underscore found (it updates the text, perhaps
>>> this triggers another parsing run).
>>> 
>>> --John
>>> 
>>> On 29/10/2021 19:53, Scott Palmer wrote:
>>>> I looked in the bug database and while there are lots of bugs reported
>>>> against the mnemonic parsing, they claim to be fixed.
>>>> 
>>>> After noticing something peculiar on a control in my app (it was
>>>> showing a
>>>> file path and I hadn't disabled the mnemonic parsing) I did some tests.
>>>> 
>>>> The documentation is unclear on what should happen if multiple
>>>> underscores
>>>> are in the text.  It just says if the mnemonic parsing character '_'
>>>> appears that the key combination will be based on the succeeding
>>>> character.  I presume that it should pick only ONE of the underscores
>>>> and
>>>> subsequent character, either the first or the last would make sense.
>>>> However, the behavior is that an unrelated character is shown as the
>>>> mnemonic and even it doesn't actually do anything.  Tested with JDK
>>>> 17.0.1
>>>> and JavaFX 17.0.1.
>>>> 
>>>> Does this behave as expected for you?
>>>> 
>>>> 
>>>> package mnemonic_parsing_bug;
>>>> 
>>>> import javafx.application.Application;
>>>> import javafx.geometry.Insets;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.CheckBox;
>>>> import javafx.scene.control.Label;
>>>> import javafx.scene.layout.VBox;
>>>> import javafx.stage.Stage;
>>>> 
>>>> public class Main extends Application {
>>>> 
>>>>    public static void main(String[] args) {
>>>>        launch(args);
>>>>    }
>>>> 
>>>>    @Override
>>>>    public void start(Stage primaryStage) throws Exception {
>>>>        Label titleLabel = new Label("""
>>>>            The CheckBox below has text set to 'How_to_Test_Mnemonics'.
>>>>            On Windows press the Alt key to see where the underlined
>>>> character appears.
>>>>            It shows under the 'e' in Mnemonics for me, and I can't
>>>> figure
>>>> out
>>>>            what key combination (if any) actually does something.
>>>>            [JavaFX Version %s]""".formatted(System.getProperty(
>>>> "javafx.version")) );
>>>>        titleLabel.setMnemonicParsing(false);
>>>>        CheckBox mnemonicCB = new CheckBox("How_to_Test_Mnemonics");
>>>>        mnemonicCB.setMnemonicParsing(true);
>>>>        VBox box = new VBox(8,titleLabel, mnemonicCB);
>>>>        box.setPadding(new Insets(16));
>>>>        Scene scene = new Scene(box);
>>>>        primaryStage.setTitle("Mnemonic Parsing Bug");
>>>>        primaryStage.setScene(scene);
>>>>        primaryStage.show();
>>>>    }
>>>> 
>>>> }
>>>> 
>>> 
>> 


From fastegal at openjdk.java.net  Sat Oct 30 09:49:10 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sat, 30 Oct 2021 09:49:10 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <4TBn3vRqwk0VEaD8Tn6S_45G-cyQGg5fEz4TuJbKpo4=.4cb01871-bd90-468c-9471-c22a75e5bfd6@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>
 <4TBn3vRqwk0VEaD8Tn6S_45G-cyQGg5fEz4TuJbKpo4=.4cb01871-bd90-468c-9471-c22a75e5bfd6@github.com>
Message-ID: <pDYXoehuqUyFmjUFrV0eV1CoHIiMBdiLTr9GoT3y9rA=.2d1f21aa-0a75-474f-a13b-08fa8b3fd6f5@github.com>

On Fri, 29 Oct 2021 23:14:07 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java line 2162:
>> 
>>> 2160:         label.autosize();
>>> 2161:         skin.updateDisplayedText();
>>> 2162:         assertEquals("foo _bar _qux", LabelSkinBaseShim.getText(label).getText());
>> 
>> Can you verify here which letter / index is picked as mnemonic? (Also in the other tests).
>
> I don't see an easy way to do that, and I'm not in favor of making private implementation details package-public just to test some internal state. Of course, mnemonic support should have been designed in a way that is more easily testable, but this PR is not the place to do that.

could be tested indirectly, though not in isolation: 

- access the actual mnenomic via accessibleAttribute
- test whether labelFor/action is working as expected when firing an alt-mnemonic onto the scene

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jhendrikx at openjdk.java.net  Sat Oct 30 10:29:11 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Sat, 30 Oct 2021 10:29:11 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <pDYXoehuqUyFmjUFrV0eV1CoHIiMBdiLTr9GoT3y9rA=.2d1f21aa-0a75-474f-a13b-08fa8b3fd6f5@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>
 <4TBn3vRqwk0VEaD8Tn6S_45G-cyQGg5fEz4TuJbKpo4=.4cb01871-bd90-468c-9471-c22a75e5bfd6@github.com>
 <pDYXoehuqUyFmjUFrV0eV1CoHIiMBdiLTr9GoT3y9rA=.2d1f21aa-0a75-474f-a13b-08fa8b3fd6f5@github.com>
Message-ID: <zh7Oa-2nETe-yQBCY_QMuQSU6FeoWEfCr-OkTQDfPQ4=.c8e78499-56d4-49c7-b2b4-dd8cd7ced05a@github.com>

On Sat, 30 Oct 2021 09:46:13 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> I don't see an easy way to do that, and I'm not in favor of making private implementation details package-public just to test some internal state. Of course, mnemonic support should have been designed in a way that is more easily testable, but this PR is not the place to do that.
>
> in the skin test, it could be tested indirectly, though not in isolation: 
> 
> - access the actual mnenomic via accessibleAttribute
> - test whether labelFor/action is working as expected when firing an alt-mnemonic onto the scene
> 
> Just noticed that there is no test of TextBinding .. that's where the correct working of the basics should be tested, shouldn't it?

How about adding a JUnit test for TextBinding instead?  The class is sufficiently complicated to warrant one, and it has quite a few branches to cover.  I think testing it through a `Control` is a bit too high level.

Something like:

    TextBinding tb = new TextBinding("complicated_mnemonic__example_(s)__");

    assertEquals("m", tb.getMnemonic());
    assertEquals(KeyCombination.M, tb.getMnemonicKeyCombination());
    assertEquals(12, tb.getMnemonicIndex());

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jhendrikx at openjdk.java.net  Sat Oct 30 10:34:12 2021
From: jhendrikx at openjdk.java.net (John Hendrikx)
Date: Sat, 30 Oct 2021 10:34:12 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <pDYXoehuqUyFmjUFrV0eV1CoHIiMBdiLTr9GoT3y9rA=.2d1f21aa-0a75-474f-a13b-08fa8b3fd6f5@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <n7dmtpkdCH1nvRz01L1mY7nrq0IsluZW-lYbtjvNWPw=.a0902203-33cb-426e-9c53-3c64b0142acb@github.com>
 <4TBn3vRqwk0VEaD8Tn6S_45G-cyQGg5fEz4TuJbKpo4=.4cb01871-bd90-468c-9471-c22a75e5bfd6@github.com>
 <pDYXoehuqUyFmjUFrV0eV1CoHIiMBdiLTr9GoT3y9rA=.2d1f21aa-0a75-474f-a13b-08fa8b3fd6f5@github.com>
Message-ID: <gAqkjVNZE6nrsQtDmhnfavNUvkS84W1Iio3J-rNnO5w=.798e2a7f-c3bc-4013-8af9-78e33269cbab@github.com>

On Sat, 30 Oct 2021 09:46:13 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> I don't see an easy way to do that, and I'm not in favor of making private implementation details package-public just to test some internal state. Of course, mnemonic support should have been designed in a way that is more easily testable, but this PR is not the place to do that.
>
> in the skin test, it could be tested indirectly, though not in isolation: 
> 
> - access the actual mnenomic via accessibleAttribute
> - test whether labelFor/action is working as expected when firing an alt-mnemonic onto the scene
> 
> Just noticed that there is no test of TextBinding .. that's where the correct working of the basics should be tested, shouldn't it?

Just noticed @kleopatra that you suggested the same thing, I definitely agree that the place to test this is in a test for `TextBinding`.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From fkirmaier at openjdk.java.net  Sat Oct 30 11:02:28 2021
From: fkirmaier at openjdk.java.net (Florian Kirmaier)
Date: Sat, 30 Oct 2021 11:02:28 GMT
Subject: RFR: 8274022 fixing critical memory leak in the
 ControlAcceleratorSupport
Message-ID: <ENoj1ikh8wPGOk1iEUb71bRR4a3Q6aWTurhyLz5utZQ=.b1faba4f-f110-4f32-a1f6-c3499c77edec@github.com>

This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
To fix it, I've made the Value of the WeakHashMap also weak. 
We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak.


I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug.

It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable.

Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe.

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

Commit messages:
 - 8274022 fixing memory leak in the ControlAcceleratorSupport

Changes: https://git.openjdk.java.net/jfx/pull/659/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=659&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274022
  Stats: 39 lines in 2 files changed: 30 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jfx/pull/659.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/659/head:pull/659

PR: https://git.openjdk.java.net/jfx/pull/659

From kcr at openjdk.java.net  Sat Oct 30 12:18:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 12:18:13 GMT
Subject: RFR: 8274022 fixing critical memory leak in the
 ControlAcceleratorSupport
In-Reply-To: <ENoj1ikh8wPGOk1iEUb71bRR4a3Q6aWTurhyLz5utZQ=.b1faba4f-f110-4f32-a1f6-c3499c77edec@github.com>
References: <ENoj1ikh8wPGOk1iEUb71bRR4a3Q6aWTurhyLz5utZQ=.b1faba4f-f110-4f32-a1f6-c3499c77edec@github.com>
Message-ID: <jpY3tasgQ9HXdbbxLsQVx1TPqt6ZjB_I1Q0Bch-qedY=.5a01af95-045b-4b4b-bf33-6207dbdc5d12@github.com>

On Sat, 30 Oct 2021 10:56:40 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
> To fix it, I've made the Value of the WeakHashMap also weak. 
> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak.
> 
> 
> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug.
> 
> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable.
> 
> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe.

>   * [JDK-8274022](https://bugs.openjdk.java.net/browse/JDK-8274022): Additional Memory Leak in ControlAcceleratorSupport ?? Title mismatch between PR and JBS.

@FlorianKirmaier as a reminder, the PR title must match the JBS title. Note that I modified the JBS title slightly, so when you do fix this, you will need to grab the updated title:


8274022: Additional Memory Leak in ControlAcceleratorSupport

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

PR: https://git.openjdk.java.net/jfx/pull/659

From kcr at openjdk.java.net  Sat Oct 30 12:47:13 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 12:47:13 GMT
Subject: RFR: 8276179 removing unused font code - isInstalledFont
In-Reply-To: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
References: <9LzqYquA9U5aehttwNaaXiDXzKS4hKI7dS7-anDmloU=.5a8d9df6-67fd-4824-b474-277f7d1df393@github.com>
Message-ID: <7Oz__wJpOM2d4Z1jjAIW3z02Yy2ZfwrmOQqBkz_jZRs=.1d28cd69-ae5e-4136-ab17-af4c3ebc9462@github.com>

On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> removing dead code.
> When looking into the font code, I've noticed that this code is no longer used, so I thought I should make a PR with a minor cleanup.

> [JDK-8276179](https://bugs.openjdk.java.net/browse/JDK-8276179): PrismFontFile.isInstalledFont is dead code and should be removed ?? Title mismatch between PR and JBS.

@FlorianKirmaier except for the above problem with the title of this PR, it is ready to be integrated. Once you update this PR's title, Skara will mark it as ready.

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

PR: https://git.openjdk.java.net/jfx/pull/658

From kcr at openjdk.java.net  Sat Oct 30 20:39:35 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:39:35 GMT
Subject: RFR: 8275911: Keyboard doesn't show when tapping inside an iOS
 text input control
In-Reply-To: <uzzdKkob2d37_tQGA51Ohy1SYKQazmZ_5EkXtjKj2qk=.6b39be86-64eb-40fa-9bdb-78cbcbd0e3e3@github.com>
References: <uzzdKkob2d37_tQGA51Ohy1SYKQazmZ_5EkXtjKj2qk=.6b39be86-64eb-40fa-9bdb-78cbcbd0e3e3@github.com>
Message-ID: <JW-AQhtyeRrPhHZSCT6tnRDuN_dzz7Jj0SLHqwdDK8g=.9a534c8e-2f2a-46dc-b7f5-9a90631bf993@github.com>

On Tue, 26 Oct 2021 11:07:50 GMT, Jose Pereda <jpereda at openjdk.org> wrote:

> After [JDK-8245053](https://bugs.openjdk.java.net/browse/JDK-8245053) for Android, this PR applies the same approach on iOS: tapping on a text input control on iOS shows the keyboard, which hides after the control loses the focus. 
> 
> Now, both platforms have the same behaviour.
> 
> Tested on an iOS device.

Changes look OK to me. Since they are confined to iOS-specific files, I'll leave it to @johanvos to review.

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

PR: https://git.openjdk.java.net/jfx/pull/653

From kcr at openjdk.java.net  Sat Oct 30 20:39:47 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:39:47 GMT
Subject: RFR: 8273485: Deadlock when also using Swing and exiting
 Fullscreen on Mac [v7]
In-Reply-To: <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
References: <W77SH4mADCPcKbWxjMkoGfDKxbEucTJqFs36fqS8jQA=.ebdccaf5-ce63-4497-98bd-470f3c9149c7@github.com>
 <zJGh-fLp7G9BtXr58I3rig5IAgi_7i2GwDeC8biDhHk=.617b7e78-4800-431a-b6ea-88c2834ceb6d@github.com>
Message-ID: <QnDJ9RvWlkvmTioHzkpJBgqMLe2aeMwc5SO_LlPskqk=.ee64f16e-693f-4b0e-b820-3854be6df339@github.com>

On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> When using Swing it's possible to generate a Deadlock.
>>  It's related to the nested eventloop started in enterFullScreenExitingLoop - and the RenderLock aquired when using setView in Scene.
>>  Sample Programm and Threaddump are added to the ticket.
>> 
>> Removing the nested loop fixes the Problem. 
>> I hope this doesn't have any side effect - so far i don't know of any.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8273485
>   Fixing toggle fullscreen!

What version of macOS did you test on? I was running on 10.15.7 (Catalina). I just tried it on macOS 11.5 (Big Sur) and the exception does not happen, and on 10.14.6 (Mojave) where is does. To summarize, when calling `Platform.exit` while in full-screen mode:

macOS 10.14.6 : exception
macOS 10.15.7 : exception
macOS 11.5 : OK

modules/javafx.graphics/src/main/native-glass/mac/GlassViewDelegate.m line 1345:

> 1343:         if (self->nativeFullScreenModeWindow)
> 1344:         {
> 1345:             [[self->nsView window] toggleFullScreen:self];

I see you added the call to `toggleFullScreen` back in, but you now pass `self` to the method, where the previous code passed `nil`. Unless there is a compelling reason why you need to change it, I recommend to restore _exactly_ the former code, such that there are no diffs:


            [self->nativeFullScreenModeWindow performSelector:@selector(toggleFullScreen:) withObject:nil];

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

PR: https://git.openjdk.java.net/jfx/pull/622

From mstrauss at openjdk.java.net  Sat Oct 30 20:40:12 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 30 Oct 2021 20:40:12 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v4]
In-Reply-To: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
Message-ID: <YuHCmvGU111ZnssGMTGJFMXI8xkI7UmYwd-NkzVxwvU=.4e898968-f26b-4316-ba0a-ba8fe29f846d@github.com>

> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.

Michael Strau? has updated the pull request incrementally with four additional commits since the last revision:

 - revert rename
 - revert rename
 - test for KeyCombination
 - renamed TextBinding to MnemonicParser, refactored tests

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

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/647/files
  - new: https://git.openjdk.java.net/jfx/pull/647/files/c4012056..5b5d720d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=647&range=02-03

  Stats: 224 lines in 3 files changed: 146 ins; 72 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/647.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/647/head:pull/647

PR: https://git.openjdk.java.net/jfx/pull/647

From kcr at openjdk.java.net  Sat Oct 30 20:40:25 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:25 GMT
Subject: RFR: 8269907 memory leak - Dirty Nodes / Parent removed [v2]
In-Reply-To: <GwUj4mH4dnEFsVR8e77nUsErRBCdrgRfFBU_TGKyQ1c=.73ca840a-1b70-4219-81cc-7d7c1b761301@github.com>
References: <NRSso6BoduAGjZ_GZ7qhvTuAayvNVb5GfhHF3gpJYBo=.abdf132e-9e9c-400f-8f27-06c76bbd643a@github.com>
 <GwUj4mH4dnEFsVR8e77nUsErRBCdrgRfFBU_TGKyQ1c=.73ca840a-1b70-4219-81cc-7d7c1b761301@github.com>
Message-ID: <iBxSIlKa8G3taXdt8R_n1L2noWQDx5Z0SLMg00U9MxM=.09a024b4-c0d9-4533-bb43-6abc0840ac0e@github.com>

On Thu, 22 Jul 2021 11:50:11 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the dirtyNodes are unset, the whole scene is basically considered dirty. 
>> This has the drawback of rerendering, whenever a window is "reshown", but it restores sanity about memory behaviour, which should be considered more important.
>
> Florian Kirmaier has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8269907
>   The bug is now fixed in a new way. Toolkit now supports registering CleanupListeners, which can clean up the dirty nodes, avoiding memoryleaks.

I took a closer look, and the current PR has at least one problem. The call to `synchronizeSceneNode` must only be done with the `renderLock` held. If you are using this in production, then it likely means you aren't hitting the cases where this would break. I recommend either my earlier suggestion of hooking into the existing listener, or else you will need to acquire the `renderLock`. If the latter, then one thing you will want to avoid is running both a regular sync pass and a cleanup pass in the same pulse. I see that you try to ensure that by only adding the listener if the scene is not showing, but since you might have to also check in the listener itself (not sure).

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

PR: https://git.openjdk.java.net/jfx/pull/584

From kcr at openjdk.java.net  Sat Oct 30 20:40:14 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:14 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
Message-ID: <Ban7d1DwTmUFMzq5S48211Is6Ngg8M7ZeCKhfzRBxjE=.17c88538-9765-4512-8f2b-929077e58c5d@github.com>

On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed javadoc

The latest changes look good (aside from the renaming of the class, which could be done separately). I'll look at the refactored tests and do some more testing next week.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jvos at openjdk.java.net  Sat Oct 30 20:40:25 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 30 Oct 2021 20:40:25 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <B0WmrGBhO7XApP_NeEZg2no42cKCkgPnkvobgXhWNHQ=.ee421f2c-5cd3-43bf-a1d7-d2122dee6465@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

Marked as reviewed by jvos (Reviewer).

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

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Sat Oct 30 20:40:26 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:26 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <3ZeTk_VNrBUacHx8T5v8ZMurRQ78jpVg3iYgNcNIOkg=.d2d4d5f6-5640-483c-92e3-bb0d2dfb8e1a@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

Marked as reviewed by kcr (Lead).

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

PR: https://git.openjdk.java.net/jfx/pull/654

From mstrauss at openjdk.java.net  Sat Oct 30 20:40:17 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 30 Oct 2021 20:40:17 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <Dt46R4_YDMpOpm96iIiGiLd7SaGkl39ngGA08ylp1Js=.84d8185e-f8a4-446e-b7fc-6ffcb9a21cbb@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <Dt46R4_YDMpOpm96iIiGiLd7SaGkl39ngGA08ylp1Js=.84d8185e-f8a4-446e-b7fc-6ffcb9a21cbb@github.com>
Message-ID: <HBwNVvesD2v1mQfABsRYCR-SnMRvBmeFg4yHp20FlnY=.ebbd1c7f-a8c9-4b1e-96f4-03e82cb0c153@github.com>

On Sat, 30 Oct 2021 14:12:17 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

> there is no need for the class rename, is there?
> 
> Even though it's formally internal api, I think we shouldn't do code breaking changes except if there's a very compelling reason - there are too many apps out in the wild that use internal api.

I don't know how `TextBinding` describes in any way what this class is doing. Naming is important, and I think `MnemonicParser`, on the other hand, describes exactly what is going on. I would disagree that treating internal APIs as if they were public APIs is a good place to be. Cleaning up and refactoring internal APIs is important for the long-term health of a codebase.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From fastegal at openjdk.java.net  Sat Oct 30 20:40:16 2021
From: fastegal at openjdk.java.net (Jeanette Winzenburg)
Date: Sat, 30 Oct 2021 20:40:16 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
Message-ID: <Dt46R4_YDMpOpm96iIiGiLd7SaGkl39ngGA08ylp1Js=.84d8185e-f8a4-446e-b7fc-6ffcb9a21cbb@github.com>

On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed javadoc

there is no need for the class rename, is there? 

Even though it's formally internal api, I think we shouldn't do code breaking changes except if there's a very compelling reason - there are too many apps out in the wild that use internal api.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From kcr at openjdk.java.net  Sat Oct 30 20:40:17 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:17 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <HBwNVvesD2v1mQfABsRYCR-SnMRvBmeFg4yHp20FlnY=.ebbd1c7f-a8c9-4b1e-96f4-03e82cb0c153@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <Dt46R4_YDMpOpm96iIiGiLd7SaGkl39ngGA08ylp1Js=.84d8185e-f8a4-446e-b7fc-6ffcb9a21cbb@github.com>
 <HBwNVvesD2v1mQfABsRYCR-SnMRvBmeFg4yHp20FlnY=.ebbd1c7f-a8c9-4b1e-96f4-03e82cb0c153@github.com>
Message-ID: <r5jA74nIdD8oBY517Hilkil6avKlLTjvd8tX1JSAYqw=.cc005d1f-ea03-4c61-af46-f270fc992dff@github.com>

On Sat, 30 Oct 2021 14:18:42 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> there is no need for the class rename, is there?
> 
> Even though it's formally internal api, I think we shouldn't do code breaking changes except if there's a very compelling reason - there are too many apps out in the wild that use internal api.

Well, internal interfaces aren't API. With JDK 9 - 16 it requires relaxing encapsulation to get at it. As of JDK 17, it requires an explicit export of the package to access it. Having said that, since this is a fix we are likely to want to backport to at least JavaFX 17.0.X, I think we should minimize the scope of the fix.

So I agree with @kleopatra (albeit for a different reason) that we shouldn't make this change.

> I don't know how `TextBinding` describes in any way what this class is doing. Naming is important, and I think `MnemonicParser`, on the other hand, describes exactly what is going on.

Agreed.

> I would disagree that treating internal APIs as if they were public APIs is a good place to be.

Completely agree.

> Cleaning up and refactoring internal APIs is important for the long-term health of a codebase.

Yes, but I would prefer to see it as a separate fix, rather than as part of a (critical) regression bug fix.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From kcr at openjdk.java.net  Sat Oct 30 20:40:26 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:26 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <zKwsQUh8B7dgfw-IeiO74X-Yboz9Fw4RAt-6UcNWfe8=.cf7681ed-708a-4ef2-adca-53a17516663b@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <AuXXb5o9rZTaT3AfdQylxWiz2BypxLg3A8Fc_EtHlMg=.60edff4b-a874-48ea-b287-aef23c28af0f@github.com>
 <zKwsQUh8B7dgfw-IeiO74X-Yboz9Fw4RAt-6UcNWfe8=.cf7681ed-708a-4ef2-adca-53a17516663b@github.com>
Message-ID: <dznaMXay4yMs4VIcPlwXbngqlMuBaSBx-K4RbYv9Cro=.951a57e3-40ca-4234-905e-6d094916a29c@github.com>

On Wed, 27 Oct 2021 16:01:10 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> If we want to be really safe we can replace a + by - or something else, but not sure if really needed.

I had the same thought as a possibility, but I'm also not sure it is needed. @johanvos what do you think?

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

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Sat Oct 30 20:40:26 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:26 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <VYFFPqmnPVwfLhLQHVSXhFAJB71eZ295rRVMuGAF4BQ=.c62653ff-6282-47e9-b2bc-8ff3e97b9bcd@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <VYFFPqmnPVwfLhLQHVSXhFAJB71eZ295rRVMuGAF4BQ=.c62653ff-6282-47e9-b2bc-8ff3e97b9bcd@github.com>
Message-ID: <OBZfSVaiYUsZem7T5UA1aGOYs6mX8y3dzJHEotEDti4=.4e419188-015c-46db-85e0-d7ee4cfb777e@github.com>

On Fri, 29 Oct 2021 14:31:02 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

> Perhaps it would also be a good idea to move these files to the user's temporary directory, so that they can be cleaned up by the system. Otherwise they probably won't be removed in most cases when the user removes the application that created them.

Maybe. If so, this would need to be done as part of a separate bug fix.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Sat Oct 30 20:40:20 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:20 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v4]
In-Reply-To: <YuHCmvGU111ZnssGMTGJFMXI8xkI7UmYwd-NkzVxwvU=.4e898968-f26b-4316-ba0a-ba8fe29f846d@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <YuHCmvGU111ZnssGMTGJFMXI8xkI7UmYwd-NkzVxwvU=.4e898968-f26b-4316-ba0a-ba8fe29f846d@github.com>
Message-ID: <LuGGoxC0wLl0XMuPcfHxx5gLim9TWkQ7SuWO3axuqys=.3345d64d-4444-4ab2-aea1-d55c6fca6500@github.com>

On Sat, 30 Oct 2021 14:49:24 GMT, Michael Strau? <mstrauss at openjdk.org> wrote:

>> This PR fixes an issue with mnemonic parsing by removing the restriction that a mnemonic symbol must be a letter. Now, it can be any character except whitespace.
>
> Michael Strau? has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - revert rename
>  - revert rename
>  - test for KeyCombination
>  - renamed TextBinding to MnemonicParser, refactored tests

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/MnemonicParser.java line 63:

> 61:  * </ul>
> 62:  */
> 63: public class MnemonicParser {

As mentioned in the comments, I prefer this rename to be reverted. It could be done separately as cleanup.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/MnemonicParser.java line 194:

> 192:             } else if (isExtendedMnemonic(s, i)) {
> 193:                 mnemonic = String.valueOf(s.charAt(i + 2));
> 194:                 mnemonicIndex = i;

Good catch. This is needed to make extended mnemonics work.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jvos at openjdk.java.net  Sat Oct 30 20:40:26 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 30 Oct 2021 20:40:26 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <OBZfSVaiYUsZem7T5UA1aGOYs6mX8y3dzJHEotEDti4=.4e419188-015c-46db-85e0-d7ee4cfb777e@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <VYFFPqmnPVwfLhLQHVSXhFAJB71eZ295rRVMuGAF4BQ=.c62653ff-6282-47e9-b2bc-8ff3e97b9bcd@github.com>
 <OBZfSVaiYUsZem7T5UA1aGOYs6mX8y3dzJHEotEDti4=.4e419188-015c-46db-85e0-d7ee4cfb777e@github.com>
Message-ID: <xBm7BnxTrGskQ8A49utRDPnxPVSJeTFchZGf7FIUHzU=.5aa9441d-2952-42bb-a6a7-afafff752763@github.com>

On Sat, 30 Oct 2021 14:46:50 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > Perhaps it would also be a good idea to move these files to the user's temporary directory, so that they can be cleaned up by the system. Otherwise they probably won't be removed in most cases when the user removes the application that created them.
> 
> Maybe. If so, this would need to be done as part of a separate bug fix.

I don't think that would be needed. We currently use the same approach as maven, and have a "permanent" cache for artifacts. There is a difference between the JavaFX libraries and application-specific components. The JavaFX jars are not linked to a specific application, but can be used by a number of applications (at build time as well as at runtime). 
I agree that application-specific components need to be removed (when possible) from the user's storage, but that is at runtime, and only when these components are only used by the specific application.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From mstrauss at openjdk.java.net  Sat Oct 30 20:40:21 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 30 Oct 2021 20:40:21 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v4]
In-Reply-To: <LuGGoxC0wLl0XMuPcfHxx5gLim9TWkQ7SuWO3axuqys=.3345d64d-4444-4ab2-aea1-d55c6fca6500@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <YuHCmvGU111ZnssGMTGJFMXI8xkI7UmYwd-NkzVxwvU=.4e898968-f26b-4316-ba0a-ba8fe29f846d@github.com>
 <LuGGoxC0wLl0XMuPcfHxx5gLim9TWkQ7SuWO3axuqys=.3345d64d-4444-4ab2-aea1-d55c6fca6500@github.com>
Message-ID: <JHF_fCOJUGYFht0d63jkSDskRLSZhCUpxzlCk_VMHc4=.ae42ee02-af2a-4945-af67-d51b6e78d8ed@github.com>

On Sat, 30 Oct 2021 14:28:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Michael Strau? has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - revert rename
>>  - revert rename
>>  - test for KeyCombination
>>  - renamed TextBinding to MnemonicParser, refactored tests
>
> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/behavior/MnemonicParser.java line 63:
> 
>> 61:  * </ul>
>> 62:  */
>> 63: public class MnemonicParser {
> 
> As mentioned in the comments, I prefer this rename to be reverted. It could be done separately as cleanup.

I created [JDK-8276206](https://bugs.openjdk.java.net/browse/JDK-8276206) to track this.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From jvos at openjdk.java.net  Sat Oct 30 20:40:27 2021
From: jvos at openjdk.java.net (Johan Vos)
Date: Sat, 30 Oct 2021 20:40:27 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <dznaMXay4yMs4VIcPlwXbngqlMuBaSBx-K4RbYv9Cro=.951a57e3-40ca-4234-905e-6d094916a29c@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <AuXXb5o9rZTaT3AfdQylxWiz2BypxLg3A8Fc_EtHlMg=.60edff4b-a874-48ea-b287-aef23c28af0f@github.com>
 <zKwsQUh8B7dgfw-IeiO74X-Yboz9Fw4RAt-6UcNWfe8=.cf7681ed-708a-4ef2-adca-53a17516663b@github.com>
 <dznaMXay4yMs4VIcPlwXbngqlMuBaSBx-K4RbYv9Cro=.951a57e3-40ca-4234-905e-6d094916a29c@github.com>
Message-ID: <WdD5KbDZKx_pxNzmLrr5fUGrnQULqCs4PtPuxusDUrA=.b226c1a3-9ab5-4325-be7b-7e76d358c5dc@github.com>

On Sat, 30 Oct 2021 14:48:14 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > If we want to be really safe we can replace a + by - or something else, but not sure if really needed.
> 
> I had the same thought as a possibility, but I'm also not sure it is needed. @johanvos what do you think?

I don't think it's needed. Either there is a potential issue with a "+" or there is not. If there is not an issue, then it is only confusing to replace the "+" with another character.
Hence, I am +1 on the PR as it is now.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From mstrauss at openjdk.java.net  Sat Oct 30 20:40:27 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sat, 30 Oct 2021 20:40:27 GMT
Subject: RFR: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <xBm7BnxTrGskQ8A49utRDPnxPVSJeTFchZGf7FIUHzU=.5aa9441d-2952-42bb-a6a7-afafff752763@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
 <VYFFPqmnPVwfLhLQHVSXhFAJB71eZ295rRVMuGAF4BQ=.c62653ff-6282-47e9-b2bc-8ff3e97b9bcd@github.com>
 <OBZfSVaiYUsZem7T5UA1aGOYs6mX8y3dzJHEotEDti4=.4e419188-015c-46db-85e0-d7ee4cfb777e@github.com>
 <xBm7BnxTrGskQ8A49utRDPnxPVSJeTFchZGf7FIUHzU=.5aa9441d-2952-42bb-a6a7-afafff752763@github.com>
Message-ID: <3O3t008hKXlrM5w8CfnwFiyo643IJIaiTwmuCn1lZLE=.e841a7ed-bb79-445c-ae1b-6ca81e1f14cf@github.com>

On Sat, 30 Oct 2021 14:54:16 GMT, Johan Vos <jvos at openjdk.org> wrote:

> I don't think that would be needed. We currently use the same approach as maven, and have a "permanent" cache for artifacts.

For users, JavaFX comes as an invisible part of an application in 99% of cases. That's different from Maven, which is consciously installed by users either manually or as part of a software development suite.
Most users of a JavaFX application did not consent to permanent changes to their system that persist even after they uninstall the application.

> There is a difference between the JavaFX libraries and application-specific components.

No, not from the perspective of a user of an application that happens to use JavaFX. The same argument could be made for every third-party library used by an application, and you wouldn't want every one of those to make permanent changes to your system, too.

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

PR: https://git.openjdk.java.net/jfx/pull/654

From kcr at openjdk.java.net  Sat Oct 30 20:40:22 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 30 Oct 2021 20:40:22 GMT
Subject: RFR: 8274854: Mnemonics for menu containing numeric text not
 working [v3]
In-Reply-To: <P3WNpZRREapG18Dv_6qC1ixdbb8iblhzqNZ9CAj6x28=.9e04b9c5-9085-4abb-acbc-2ce5a3bb610b@github.com>
References: <dc1W_Gr82g6Kl1hJaW1PXoq_mAFEUZMmnNfPyz2wFSM=.611bf78b-d9ab-4d9c-bb27-60b670bc67cb@github.com>
 <xjZGlSQhDeSQsHWyyw7z9YToqseDLSzCC8zPuZ4mjVQ=.e0f83bcf-3efc-4f01-910d-63fe4dd7656d@github.com>
 <bIltMhs5TCiZd1zz5HwGmxV9RCWUMwb6c8wO36KQQY8=.fd0353b5-f256-41fc-955c-64fe2305749a@github.com>
 <L73UMDAyqNXeNBX1mbYTXPmzxMH9dGLUhK1LtJBnt50=.071c4db9-abcd-441e-8355-6a2ccf0d327a@github.com>
 <P3WNpZRREapG18Dv_6qC1ixdbb8iblhzqNZ9CAj6x28=.9e04b9c5-9085-4abb-acbc-2ce5a3bb610b@github.com>
Message-ID: <s8-8lPePuIWukcBb2InJqyNyuQKzeDS5LSa-HQMgAzw=.f548ec97-1d87-4e8d-9724-97a9885f90b4@github.com>

On Fri, 29 Oct 2021 22:18:58 GMT, John Hendrikx <jhendrikx at openjdk.org> wrote:

>> This PR does not add any additional feature. It restores the behavior of jfx16, where any character is acceptable as a mnemonic, and the first mnemonic is selected.
>
> Okay, the wording of the JBS ticket suggested something else, but I see it is just a regression fix.

Yes, exactly. There were two bugs introduced with the previous fix: First, digits or other symbols are no longer recognized as mnemonics. Second, the last `_` is used rather than the first. It looks like this fixes both problems.

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

PR: https://git.openjdk.java.net/jfx/pull/647

From mhanl at openjdk.java.net  Sat Oct 30 20:40:27 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Sat, 30 Oct 2021 20:40:27 GMT
Subject: Integrated: 8222455: JavaFX error loading glass.dll from cache
In-Reply-To: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
References: <5NldaQLlg4dWVUuICieZ39zYmFrwJONpSb9dzW6TkE0=.42122cdb-60aa-450b-bb03-5d53c98370c5@github.com>
Message-ID: <0vhC-Ri43KACIjZuALAzNUapdQLamPR_uOlDMyXr8WQ=.14e9f1bf-0213-4b21-bbb1-cc062a8f0916@github.com>

On Tue, 26 Oct 2021 12:09:19 GMT, Marius Hanl <mhanl at openjdk.org> wrote:

> This problem can happen when using multiple instances with different jfx early access (ea) versions.
> 
> Example: 
> Instance 1 uses 18-ea+4 and Instance 2 uses 18-ea+1. 
> Instance 1 is started (and will cache and use libraries), then instance 2. 
> Now instance 2 detects via a hash comparison that the cached libraries are not the same as the supplied ones. 
> With this information instance 2 tries to delete the old libraries but fails while doing so (as instance 1 uses them currently) and will terminate right after.
> 
> The problem here is that instance 1 and 2 are using the same cache folder: **18-ea**. This is because the `NativeLibLoader` uses the `javafx.version` property for determining the folder name, which in case of an ea version will always be **18-ea** (for all ea versions starting with 18 obviously).
> 
> Fix as also mentioned in the ticket is to use the `javafx.runtime.version` property instead. 
> With this the folders will be named 18-ea+1 and 18-ea+4.

This pull request has now been integrated.

Changeset: 6c881063
Author:    Marius Hanl <mhanl at openjdk.org>
Committer: Kevin Rushforth <kcr at openjdk.org>
URL:       https://git.openjdk.java.net/jfx/commit/6c8810634ec63af8116dd978656805b985eec800
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8222455: JavaFX error loading glass.dll from cache

Reviewed-by: jvos, kcr

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

PR: https://git.openjdk.java.net/jfx/pull/654

From mstrauss at openjdk.java.net  Sun Oct 31 16:39:07 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 31 Oct 2021 16:39:07 GMT
Subject: RFR: 8274022 fixing critical memory leak in the
 ControlAcceleratorSupport
In-Reply-To: <ENoj1ikh8wPGOk1iEUb71bRR4a3Q6aWTurhyLz5utZQ=.b1faba4f-f110-4f32-a1f6-c3499c77edec@github.com>
References: <ENoj1ikh8wPGOk1iEUb71bRR4a3Q6aWTurhyLz5utZQ=.b1faba4f-f110-4f32-a1f6-c3499c77edec@github.com>
Message-ID: <TOf1L_Cd8L25xBunGQ-wdeKAwRRBWm3jsyoOtYs4VdM=.b58df7d1-b2a6-4423-b204-2d220d6ecfd0@github.com>

On Sat, 30 Oct 2021 10:56:40 GMT, Florian Kirmaier <fkirmaier at openjdk.org> wrote:

> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
> To fix it, I've made the Value of the WeakHashMap also weak. 
> We only keep this value to remove it as a listener later on. Therefore there shouldn't be issues by making this value weak.
> 
> 
> I've seen this Bug very very often, in the last weeks. Most of the applications I've seen are somehow affected by this bug.
> 
> It basically **breaks every application with menu bars and multiple stages** - which is the majority of enterprise applications. It's especially annoying because it takes some time until the application gets unstable.
> 
> Therefore **I would recommend** after this fix is approved, **to make a new version for JavaFX17** with this fix because this bug is so severe.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 31:

> 29: import javafx.beans.property.ReadOnlyObjectProperty;
> 30: import javafx.beans.value.ChangeListener;
> 31:  import javafx.beans.value.WeakChangeListener;

Minor: whitespace at the beginning of the line

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 88:

> 86:         // Remove previously added listener if any
> 87:         if (sceneChangeListenerMap.containsKey(anchor)) {
> 88:             ChangeListener<Scene> listener = sceneChangeListenerMap.get(anchor).get();

It seems unusual to check for the existence of a weak key (containsKey), and then just assume it still exists (get). You should probably get() the value directly without checking containsKey() first, and then check whether the returned value is null.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 89:

> 87:         if (sceneChangeListenerMap.containsKey(anchor)) {
> 88:             ChangeListener<Scene> listener = sceneChangeListenerMap.get(anchor).get();
> 89:             if(listener != null) {

Minor: space before brace

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 254:

> 252:             // at the time of installing the accelerators.
> 253:             if (sceneChangeListenerMap.containsKey(anchor)) {
> 254:                 ChangeListener<Scene> listener = sceneChangeListenerMap.get(anchor).get();

It seems unusual to check for the existence of a weak key (containsKey), and then just assume it still exists (get). You should probably get() the value directly without checking containsKey() first, and then check whether the returned value is null.

modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/ControlAcceleratorSupport.java line 255:

> 253:             if (sceneChangeListenerMap.containsKey(anchor)) {
> 254:                 ChangeListener<Scene> listener = sceneChangeListenerMap.get(anchor).get();
> 255:                 if(listener != null) {

Minor: space before brace

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

PR: https://git.openjdk.java.net/jfx/pull/659

From mstrauss at openjdk.java.net  Sun Oct 31 16:55:13 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 31 Oct 2021 16:55:13 GMT
Subject: RFR: 8201538: Remove implementation support for applets from
 JavaFX
In-Reply-To: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com>
References: <5Fxtt0GR8oAqedsdK2MPeebV4mv9C9x_wUvxi9x7iQM=.4b35e2c4-2971-4880-be6f-7a751474befb@github.com>
Message-ID: <EBmw-55TwpTrThg5CDSBhlRC7H91PGvUm94UJqK5Y2g=.69944e80-9247-47be-9b17-13bba125adcc@github.com>

On Tue, 31 Aug 2021 16:28:53 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This PR removes the obsolete applet implementation from JavaFX. It is an ongoing maintenance burden to carry around this legacy code. Also, cleaning this up could help in the implementation of GTK4, Wayland, and Metal, since we won't have to account for the way applet windows are created and managed.
> 
> ## Notes to reviewers:
> 
> The first part of the removal was to eliminate the methods and classes on the Java side that are associated with creating and managing an applet window, and which are no longer called. After these were removed, I then removed the corresponding methods and classes on the native side that are no longer called.
> 
> ### Shared Code
> 
> The following were removed from the shared code.
> 
> #### Removed Java classes
> 
> 
> com.sun.javafx.tk.AppletWindow
> com.sun.javafx.tk.quantum.GlassAppletWindow
> 
> 
> #### Removed methods
> 
> The following methods were removed in the parent class and all subclasses.
> 
> 
> com.sun.glass.ui.Application:
>     public abstract Window createWindow(long parent)
> 
> com.sun.glass.ui.Window:
>     public boolean getAppletMode()
>     public void setAppletMode(boolean appletMode)
>     public void dispatchNpapiEvent(Map eventInfo)
>     protected abstract long _createChildWindow(long parent)
>     protected Window(long parent)
>     protected abstract int _getEmbeddedX(long ptr)
>     protected abstract int _getEmbeddedY(long ptr)
> 
> com.sun.javafx.tk.Toolkit:
>     public abstract AppletWindow createAppletWindow(...)
>     public abstract void closeAppletWindow()
> 
> com.sun.javafx.tk.quantum.WindowStage:
>     static void setAppletWindow(GlassAppletWindow aw)
>     static GlassAppletWindow getAppletWindow()
> 
> 
> 
> ### Linux (Gtk) Java code
> 
> The following classes or methods were removed:
> 
> 
> com.sun.glass.ui.gtk.GtkChildWindow (class removed)
> 
> com.sun.glass.ui.gtk.GtkWindow:
>     protected GtkWindow(long parent)
> 
> 
> ### Linux (Gtk) native glass:
> 
> The following native classes were removed:
> 
> 
> WindowContextChild
> WindowContextPlug
> 
> 
> ### macOS Java code
> 
> The following classes or methods were removed:
> 
> 
> com.sun.glass.events.mac.NpapiEvent (class removed)
> 
> com.sun.glass.ui.mac.MacApplication:
>     native protected String _getRemoteLayerServerName()
> 
> com.sun.glass.ui.View:
>     public int getNativeRemoteLayerId(String serverName)
> 
> com.sun.glass.ui.mac.MacView:
>     native protected int _getNativeRemoteLayerId(long ptr, String serverName)
>     native protected void _hostRemoteLayerId(long ptr, int nativeLayerId)
> 
> com.sun.glass.ui.mac.MacWindow:
>     protected MacWindow(long parent)
> 
> 
> ### macOS native code
> 
> The following native classes were removed:
> 
> 
> GlassEmbeddedWindow*
> GlassNSEvent
> GlassView3D+Remote
> RemoteLayerSupport
> 
> 
> I also removed the `jIsChild` parameter from the window creation code which allowed for removing a lot of dead blocks of code. The main window creation method was:
> 
> 
> - (id)_initWithContentRect:(NSRect)contentRect styleMask:(NSUInteger)windowStyle
>         screen:(NSScreen *)screen jwindow:(jobject)jwindow jIsChild:(jboolean)jIsChild
> 
> 
> This created a `GlassEmbeddedWindow` iff `jIsChild == JNI_TRUE`. Since `jIsChild` was only set to true by the (now removed) `_createChildWindow(long)` method, we can remove the parameter, the `GlassEmbeddedWindow*` classes, and all code blocks that are qualified by `if (jIsChild)`.
> 
> ### Windows Java code 
> 
> The following classes or methods were removed:
> 
> 
> com.sun.glass.ui.win.WinChildWindow (class removed)
> 
> com.sun.glass.ui.win.WinWindow:
>     protected WinWindow(long parent)
> 
> 
> ### Windows native code
> 
> After removing all references to `IsChild()`, which was only ever true for `_createChildWindow()`, we can also remove the following:
> 
> 
> GlassApplication::InstallMouseLLHook
> GlassApplication::UninstallMouseLLHook
> 
> 
> ### iOS Java code
> 
> 
> com.sun.glass.ui.ios.IosWindow:
>     protected IosWindow(long parent)
> 
> 
> ### iOS native code
> 
> With the removal of the `_createChildWindow` method, the following JNI method in `IosWindow` can be removed:
> 
> 
> Java_com_sun_glass_ui_ios_IosWindow__1createChildWindow(JNIEnv *, jobject, jlong)
> 
> 
> As a note, I don't have a setup to build this. It is a simple, safe change, but should be double-checked by someone from Gluon.

This PR does what I would expect it to do. I tested it by building an application on all three desktop platforms and it works as usual.

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

Marked as reviewed by mstrauss (Author).

PR: https://git.openjdk.java.net/jfx/pull/615

From mstrauss at openjdk.java.net  Sun Oct 31 17:09:11 2021
From: mstrauss at openjdk.java.net (Michael =?UTF-8?B?U3RyYXXDnw==?=)
Date: Sun, 31 Oct 2021 17:09:11 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
 <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
Message-ID: <jTt0RWGMpD2_kcCYuE9_FMFXEJ5ugaP_nCca3PDl6wQ=.0558fd56-06c9-4e9f-bd1e-78abb86f8f9b@github.com>

On Wed, 27 Oct 2021 09:56:46 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Cleanup of Tree-/TableRowSkin to support switching skins
>> 
>> The misbehavior/s
>> - memory leaks due to manually registered listeners that were not removed
>> - side-effects due to listeners still active on old skin (like NPEs)
>> 
>> Fix
>> - use skin api for all listener registration (for automatic removal in dispose)
>> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))
>> 
>> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins.
>> 
>> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-added forgotten code comments

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 299:

> 297:     @Override protected ObjectProperty<Node> graphicProperty() {
> 298:         TreeTableRow<T> treeTableRow = getSkinnable();
> 299:         // FIXME: illegal access if skinnable is null

What is the purpose of removing the null check, but leaving getSkinnable() in there?
Given the signature of the method, it seems that it shouldn't ever return `null` in any case.

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

PR: https://git.openjdk.java.net/jfx/pull/632

From mhanl at openjdk.java.net  Sun Oct 31 18:11:13 2021
From: mhanl at openjdk.java.net (Marius Hanl)
Date: Sun, 31 Oct 2021 18:11:13 GMT
Subject: RFR: 8274061: Tree-/TableRowSkin: misbehavior on switching skin
 [v2]
In-Reply-To: <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
References: <k776550vHGvC7dyGufux1E1PIUqwjTSZ7LtTbqszE7Q=.aef7ec1b-b5d2-4a94-88f3-3e02d7dd40a1@github.com>
 <i47E5xQ5Jh6NLIXunLXiejoCHAYZ-GZNsqBYwOPhoKU=.9055b3b2-cdf2-4ba1-9a8c-4f7dfec9e023@github.com>
Message-ID: <trF4x46Cau7N36NoeycWNjnjKX0_UxrbR1C1WCl3qvc=.cf30a225-4210-49cc-bc18-22ad452095a6@github.com>

On Wed, 27 Oct 2021 09:56:46 GMT, Jeanette Winzenburg <fastegal at openjdk.org> wrote:

>> Cleanup of Tree-/TableRowSkin to support switching skins
>> 
>> The misbehavior/s
>> - memory leaks due to manually registered listeners that were not removed
>> - side-effects due to listeners still active on old skin (like NPEs)
>> 
>> Fix
>> - use skin api for all listener registration (for automatic removal in dispose)
>> - do not install listeners that are not needed (fixedCellSize, same as in fix of ListCellSkin [JDK-8246745](https://bugs.openjdk.java.net/browse/JDK-8246745))
>> 
>> Added tests for each listener involved in the fix to guarantee it's still working and does not have unwanted side-effects after switching skins.
>> 
>> Note: there are pecularities in row skins (like not updating themselves on property changes of its control, throwing NPEs when not added to a VirtualFlow) which are not part of this issue but covered in [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
>
> Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-added forgotten code comments

modules/javafx.controls/src/main/java/javafx/scene/control/skin/TreeTableRowSkin.java line 365:

> 363:                 // Fix for RT-27782: Need to set isDirty to true, rather than the
> 364:                 // cheaper updateCells, as otherwise the text indentation will not
> 365:                 // be recalculated in TreeTableCellSkin.leftLabelPadding()

Actually this comment is not correct anymore since my PR got merged (https://github.com/openjdk/jfx/pull/568).
Instead, it should be `TreeTableCellSkin.calculateIndentation()`.

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

PR: https://git.openjdk.java.net/jfx/pull/632