Dealing with nested events for a single property in JavaFX

[Jonathan Giles]

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>> 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
>
>