On Wed, 21 Oct 2026 11:28:18 GMT, John Hendrikx <[email protected]> wrote:
> For more arbitrary property manipulation, I've also got a different system, > but it requires wrapping all properties that should participate in a > transaction. If we ever add something like this to FX (where we can change > the property code itself) the wrapping may not be needed. The > `UpdatableValue` system is more light-weight, and works much more like how > read only properties work. This looks promising. I also thought about a potential system and what I came up with (untested, just a random shower thought really): var listenerCallback = property.setSilent(12); ... listenerCallback.run(); Then, the same idea like your batch, adding all those callbacks to a `List` and then run them sequentially. This was based on how I would like to see the CSS code, because there is so much logic in for loops, that this was the only idea where we could first 'collect' callbacks and then later execute them sequentially. It is really the same concept as your idea, but with more overhead and the CSS stuff in mind. And your idea works like a single transaction, which I like more. Under the hood, do you still notify each listener sequentially, or do you have another logic in place for such a transaction? If we find a good way how we could use this with some kind of 'collect' phase / easy mechanism to track and then fire the transaction, I think this might solve all problems. Also does this solve the issues that were reported (also partly by you) where sometimes JavaFX methods are called in a re-entrant way, messing up the layout or internal state completely? I think cases like this: https://bugs.openjdk.org/browse/JDK-8387639 and https://bugs.openjdk.org/browse/JDK-8369617 are the usual result of this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4336391814
