On Tue, 4 Mar 2025 19:28:29 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>> There is an even more fundamental problem: JavaFX properties are not >> thread-safe. You cannot safely add a listener or binding to a property in >> one thread while another thread modifies that property's value. >> >> So I think that deferring the binding to >> `Platform::accessibilityActiveProperty` is the only viable approach.There >> might still be an opportunity to simplify it a bit along the lines of what >> John mentions, as long as the code that binds to the property is guaranteed >> to be run on the FX application thread. >> >> We can be certain that setting the window property to a non-null value only >> happens on the FX app thread (`Stage::setScene` enforces that threading >> constraint). > > @kevinrushforth I don't know, I would think it should be possible to create a > property or property wrapper to make it thread-safe. Just having a version > with all its methods synchronized is probably sufficient. If that saves a > lot of complex logic in, what looks like, dozens of controls, then it seems > like a far better solution to me. Of course, that should only apply to > special properties; I'm not suggesting making all properties synchronized -- > although I think we could as, without contention (since they're supposed to > be used from a single thread), it would be nearly free, and it would make all > kinds of undefined behavior scenario's when used from multiple threads (by > accident or otherwise) suddenly deterministic and debuggable. I think the problem is in the callbacks themselves, as they'd be on the wrong thread. I vaguely remember experimenting with a system where you can provide an Executor for callbacks (like `Platform::runLater`) to mitigate this. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1697#discussion_r1980114654
