Dealing with nested events for a single property in JavaFX

[Eric Le Ponner]

Hi All,

Some comments from the application developer point of view:

1)  I don't see RT-22478 and RT-17772 exactly in the same way. 

I fully agree that RT-17772 can be considered as "user error". FX API
is legitimate to refuse that a <<change listener tries to change itself the value>> . 
A "ConcurrentModification" like exception would be nice but not mandatory
in my opinion. It is up to the developer to take care.

However RT-22478 refers to the onAction() event listener.  Although the FX
implementation invokes it from a value change listener, from an API spec
point of view, this relation does not look like something implicit to me. 
Calling setValue() from onAction() is something that I would be quickly
tempted to do. In fact, RT-22478 does not reveal a "user error"  but more
a lack of specification in ComboBox API spec.

2) So are we allowed to call setValue() from onAction() ? It's your call guys. 

However this decision must be carefully taken and very well documented. 
Especially if Platform.runLater() is the sole answer that is given the application 
developer to solve her problem.

In my own experience invokeLater / runLater / performSelectorOnMainThread tend to
transform the "beauty of event management" into a "big nightmare" whether it is 
Swing, FX or MacOSX…

My two cents.

Eric





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