Detecting threading problems faster

[John Hendrikx]

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.