Dealing with nested events for a single property in JavaFX

[Jonathan Giles]

The point is: can we have a better solution by considering changing the 
event API such that it queues events, rather than do them immediately as 
they are fired.

-- Jonathan

On 22/06/2012 10:46 a.m., Slavko Scekic wrote:
> So, the point is: be careful? :)
>
> On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles 
> <jonathan.giles at oracle.com <mailto:jonathan.giles at oracle.com>> wrote:
>
>     runLater is wrong more often than it is right - so you're right -
>     I don't think we should consider that approach (or requiring
>     people to have to know to do this)
>
>     Saying that you should error out when someone tries to update a
>     property in the event callback is also wrong, I think. There are
>     legitimate use cases, for example as a last ditch form of
>     validation: if the value is outside the allowable range, change it
>     back to something that is valid. Alternatively, when focus is
>     given to a node, request a focus change on another node. I imagine
>     our own code would blow up if we took this approach :-)
>
>     -- Jonathan
>
>
>     On 22/06/2012 10:31 a.m., Daniel Zwolenski wrote:
>
>         Similar to the ConcurrentModification thing you get with
>         Collections right? Could it be handled in a similar way, i.e.
>         throw an error if someone tries to update the property they
>         are modifying while in the update callback for that property?
>         As you say, it's user error, so slapping them on the wrists is ok.
>
>         The runLater one feels like it could cause its own problems to
>         me. The 'single' threadedness of JFX is part of it's design.
>         It gives me deterministic behaviour, this feels like it could
>         open up small cracks in that. Obviously we wouldn't get
>         concurrency/deadlock issues but I suspect we could get things
>         in a non-deterministic order as a result of this (e.g. if
>         another thread does a runLater somewhere else in the code at
>         the same time this runLater is being added). Could end up that
>         my property change is overwritten sometimes but not others,
>         etc (I'm going more off gut feel here though than concrete
>         examples).
>
>
>         On Fri, Jun 22, 2012 at 8:20 AM, Jonathan Giles
>         <jonathan.giles at oracle.com <mailto:jonathan.giles at oracle.com>
>         <mailto:jonathan.giles at oracle.com
>         <mailto:jonathan.giles at oracle.com>>> wrote:
>
>            Hi all,
>
>            I'm going to keep this brief as I'm fairly comprehensively
>            underwater on the bug count.
>
>            Recently I've found a pattern of bug that, well, I'm fairly
>         sure
>            is due to user error, but is not obvious at all (and as such it
>            leads to bug reports). In the last week, I've encountered this
>            issue twice. The basic issue is that of listening to an
>         event (for
>            example, a focus change event), and reacting in such a way
>         as to
>            modify the state of this property (which results in another
>         event
>            being fired). The end result is non-deterministic (but often
>            broken behavior). Interestingly, it has in both my cases
>            manifested itself as something that works once, and then fails
>            after that forever more.
>
>            In both cases, after much code digging and debugging (although
>            today was made much easier by the same issue last week), I
>         believe
>            the issue can be worked around simply by wrapping the change to
>            the property state (in the event callback) with a
>            Platform.runLater(new Runnable() { ...}). This forces the
>         second
>            property update to happen after the first event has finished
>            firing (at some point in the future).
>
>            However, this isn't a great solution - we're forcing the
>         event to
>            fire at a later date where the state may have already
>         changed. The
>            better solution, in my opinion, is to improve the event system
>            such that it knows whether an event is already firing, and
>         if so
>            it will queue up the event to run after the current one has
>            finished. I would be interested in hearing whether anyone
>         else has
>            encountered this kind of bug, or whether they have better
>         suggestions.
>
>            You can see two examples of this bug in the code attached here
>            (where the first example is for ComboBox where the value is
>            updated in the onAction callback....which is called when value
>            changes):
>
>         http://javafx-jira.kenai.com/browse/RT-22478
>         http://javafx-jira.kenai.com/browse/RT-17772
>
>            -- Jonathan
>
>
>
>
>