On Mon, 19 Oct 2026 11:20:54 GMT, Marius Hanl <[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. 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 paths that are near impossible to exercise and then almost never occur in the wild but still must be taken into account just in case. Better to address the root cause, and then not only being able to write the code much more directly, but also being able to proof that it is correct in all cases as there no longer is user callback interference. I like to think that current JavaFX properties in complex controls is like writing a database program without having transactions. Sure, you may be able to catch all possible problems and compensate for the lack of transactions, but we're talking about a ton of code for situations that shouldn't even occur in the first place. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4320794043
