Dealing with nested events for a single property in JavaFX

[Daniel Zwolenski]

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>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-22478>
> http://javafx-jira.kenai.com/**browse/RT-17772<http://javafx-jira.kenai.com/browse/RT-17772>
>
> -- Jonathan
>