On Tue, 20 Oct 2026 02:13:33 GMT, John Hendrikx <[email protected]> wrote:
>> Thanks for your understanding! >> >> The property (listener) system in JavaFX really has this downside: you can't >> rely on any state. Developers can simply add a listener and revert the >> state, change something else, or even modify the whole scene structure! So >> it's very hard to find the right balance. >> >> Most of the time you won't notice (it just works), but as soon as a case >> gets a bit more complex or unusual, like this one or CSS, you end up playing >> whack-a-mole with edge cases: trying to think of every possible shenanigan a >> developer could do, and then fixing, avoiding, or detecting it. >> >> This is super hard to get right, and even worse: There is no perfect >> solution. >> >> For `VirtualFlow`, we have another super weird case here: >> >> https://github.com/openjdk/jfx/blob/cb56d4c90fe7a43079688b92c54c7d2b364c7232/modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java#L475-L500 >> >> Both (this and the linked) case are not called in my testing anyway, so >> probably again from the 2011 closed source we will never know era. >> >> And in the table, we also play the game of 'developer may changed focus, >> maybe not, lets try to find out with walking the scene tree': >> >> https://github.com/openjdk/jfx/blob/cb56d4c90fe7a43079688b92c54c7d2b364c7232/modules/javafx.controls/src/main/java/javafx/scene/control/TableCell.java#L358-L366 >> >> Thats also why https://github.com/openjdk/jfx/pull/1081 is a good step. But >> the problem remains: I can not trust any state, developers may override it >> in a listener. This is one of the biggest problems in JavaFX without a good >> solution. >> >> Or to say it in other words: If we could process the layout and css without >> the developer potentially interfering, and we notify the listeners after we >> are done, we won't have any of the current problems, not in CSS, not this >> discussion. > >> Thanks for your understanding! >> >> The property (listener) system in JavaFX really has this downside: you can't >> rely on any state. Developers can simply add a listener and revert the >> state, change something else, or even modify the whole scene structure! So >> it's very hard to find the right balance. >> >> Most of the time you won't notice (it just works), but as soon as a case >> gets a bit more complex or unusual, like this one or CSS, you end up playing >> whack-a-mole with edge cases: trying to think of every possible shenanigan a >> developer could do, and then fixing, avoiding, or detecting it. > > I do have a solution for this, that I use for my own programs. They're > basically a different kind of property that allows the owner of the property > (ie. the control, table, whatever) to control when listeners fire (something > we see already in some areas of FX where properties are "customized" to delay > firing, but that's usually manual and not coordinated across multiple > properties). > > For example, if I need to change 3 properties, but they're all related (let's > say x,y,z) I can change all three, and only at the end of my changes have the > listeners fire. This buys me two things: > > - I can make all my changes, and users never observe unrelated x,y,z values > (ie. if they have a listener on `x` that queries `y`, they will see the > correct pair of values) > - I don't have to worry that when I change `x` that someone changes `y` or > changes `x` back as no user hook will fire until I'm done with what I want to > do -- this makes code so much simpler as insane edge cases don't have to be > taken into account (like what if I register a listener on the children list, > that re-orders them, or what if register a listener on XYZ that starts a > nested event loop and then triggers layout...) > > This is basically a general problem for any program that allows arbitrary > callbacks (which in JavaFX are often hidden in events/listeners). Calling any > callback while you're structure isn't in a fully consistent state is > problematic if your code must continue working no matter what silly things > the user might do there. > > I think that's really one of the next areas (after correct old/new values > which was merged now) that JavaFX may see huge benefits from, especially for > insanely complex controls like `TableView`. > >> This is super hard to get right, and even worse: There is no perfect >> solution. > > And even worse than that: a complete waste of time to fix, as you spend a ton > of code on these edge cases, code pat... > I am not sure why the original developers decided that cells are precious and > need to be cached and reused. Maybe because the Node is heavy with all these > properties, I don't know. Perhaps, with gigabytes of RAM, we don't even care. > The cells should not be reused, much like popups and menus. The cell factory is user provided, and so cells may be arbitrarily heavy. For example, in my media application, a cell consists of about 20 sub nodes, including a few image nodes. Creating more of those than strictly needed is a waste. Not resetting them when not in use can hold on to an image (a video cover) that is potentially several MB's in size. I think FX not being aggressive enough with resetting/trimming is one of the reasons I wrote my own virtual container for this specific case. This is also basically what every other toolkit does, and for good reason. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4320958234
