Dealing with nested events for a single property in JavaFX

[Slavko Scekic]

So, the point is: be careful? :)

On Fri, Jun 22, 2012 at 12:39 AM, Jonathan Giles
<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<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
>>
>>
>>
>
>