Hello,
Wouldn't it be better to implement this check in assert to avoid any impact
in production?
пн, 5 авг. 2024 г. в 03:30, John Hendrikx <john.hendr...@gmail.com>:
> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model used by JavaFX. Basically, anything directly or
> indirectly linked to an active Scene must be accessed on the FX thread.
> However, as FX also allows manipulating nodes and properties before
> they're displayed, there can be no "hard" check everywhere to ensure we
> are on the FX thread (specifically, in properties).
>
> Now, I think this situation is annoying, as a simple mistake where a
> Platform.runLater wrapper was forgotten usually results in programs
> operating mostly flawlessly, but then fail in mysterious and random and
> hard to reproduce ways. The blame is often put on FX as the resulting
> exceptions will almost never show the user code which was the actual
> culprit. It can result in FX being perceived as unstable or buggy.
>
> So I've been thinking if there isn't something we can do to detect these
> bugs originating from user code much earlier, similar to the
> `ConcurrentModificationException` the collection classes do when
> accessed in nested or concurrent contexts.
>
> I think it may be possible to have properties check whether they're part
> of an active scene without too much of an performance impact, possibly
> even behind a switch. It would work like this:
>
> Properties involved with Nodes will have an associated bean instance
> (`getBean`). This is an object, but we could check here if this
> instance implements an interface:
>
> if (getBean() instanceof MayBePartOfSceneGraph x) {
> if (x.isPartOfActiveScene() && !isOnFxThread()) {
> throw new IllegalStateException("Property must only be
> used from the FX Application Thread");
> }
> }
>
> This check could be done on every set of the property, and potentially
> on every get as well. It should be relatively cheap, but will expose
> problematic code patterns at a much earlier stage. There's a chance
> that this will "break" some programs that seemed to be behaving
> correctly as well, so we may want to put it behind a switch until such
> programs (or libraries) can be fixed.
>
> What do you all think?
>
> --John
>
> (*) Names of methods/interfaces are only used for illustration purposes,
> we can think of good names if this moves forward.
>
>
