JavaFX Task/Service thread checks

[Richard Bair]

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