JavaFX Task/Service thread checks
hjohn at xs4all.nl
Mon Jun 11 01:48:50 PDT 2012
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.
More information about the openjfx-dev