JavaFX Task/Service thread checks

John Hendrikx hjohn at
Mon Jun 11 14:06:30 PDT 2012

Could you explain what the issues are when different Threads have 
listeners attached to a Task's stateProperty?  AFAIK, all the listeners 
get fired (one by one) on the fx thread, not on the thread that attached 
the listener in the first place.

I can understand that a method like setState() (if it existed) must be 
called from the fx-thread, as that could cause listeners to fire (which 
must be on the fx thread afaik)... but attaching a listener should be 
possible from any thread (barring issues with managing and traversing 
the listener list itself -- those would need synchronization) ...... I 
guess that last one probably touches upon why this thread check is there 
as the other thread would be holding a lock preventing the fx-thread 
from proceeding -- although such a lock would never be held for long...

I'll add a JIRA issue to track it.

On 11/06/2012 22:49, Richard Bair wrote:
> Hi John,
> This is a good question. Can you file a feature request? One possible solution is that whatever thread created the Task / Service is the thread that is authorized to attach listeners etc, and then also possibly have a "setOwnerThread" method (or whatnot) for changing what that owner thread is.
> There are several issues here which are annoying. One is that, for example, if you create a bunch of Tasks on the preloader startup thread (which may be different from the fx app thread) and then either (a) they don't work or (b) they are later touched from the fx app thread and you have several threads talking to the same Task.
> Richard
> On Jun 11, 2012, at 1:48 AM, John Hendrikx wrote:
>> Hi all,
>> JavaFX currently provides many interesting new ways of doing things we've been doing for years.  For example, I find myself using JavaFX packages outside the scope of the UI more and more often.  Examples are changing domain objects to include the JavaFX style Property methods for easy binding and using Task objects to make use of its convenient State property (to which one can attach listeners).
>> However, I'm wondering, why is there a 'checkThread' in for example the stateProperty method of a Task?  Wasn't it said that manipulating JavaFX objects that are NOT part of a Scene was to be allowed on any thread?  Do I need to worry that other (reusable without UI) API's in JavaFX will have this checkThread method sprinkled through them?
>> I mean, shouldn't it be allowed to create a new Task object, have it get executed on some thread of my choosing, and then be able to monitor its progress by attaching a ChangeListener to its State property?  This is a lot more convenient than say a FutureTask, for which I'm forced to either wrap it inside another Runnable (to do a little bit of clean-up after it finished, on the same thread), create another thread so I can use the blocking 'get()' call or adding a simplistic Listener system to it notify me when it completes (again, on the same thread).
>> My Task is not attached to the UI in any way, yet it forces me to wrap the call to 'stateProperty()' in a Platform.runLater() -- all I want is its feedback when it finishes without me having to build this system myself or spawning yet another Thread.
>> Best regards,
>> John Hendrikx

More information about the openjfx-dev mailing list