JavaFX Task/Service thread checks

John Hendrikx hjohn at
Mon Jun 11 01:48:50 PDT 2012

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