Platform#runLater Question

[Richard Bair]

Hi Anthony, he's talking about http://docs.oracle.com/javafx/2/api/javafx/concurrent/Task.html and related API in the javafx.concurrent package.

The answer is yes, the onXXX methods of Task are called on the FX thread, and as such, you don't need to perform another runLater. There's a large amount of documentation that should (hopefully) clearly detail which threads which methods are called on (and which methods can be called from any thread vs. only the FX thread). But in general on Task only the "call" method is called on a background thread, and you may call any of the updateXXX methods from the background thread but all other methods are on the FX thread.

Cheers
Richard

On Apr 2, 2013, at 6:31 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> (Please use "Reply All" when replying to a mailing list. Thank you.)
> 
> I'm not sure what Task you mean here, and how you started its execution in the first place. But if I assume you've followed my advice and created your own executor service and submitted your task to it, then the answer is no. The executor service doesn't know anything about FX or its event thread. I suggest to use runLater() in your onSucceeded and onFailed implementations for your task if you need this code to perform some GUI-related operations.
> 
> --
> best regards,
> Anthony
> 
> On 4/2/2013 17:23, Mark Fortner wrote:
>> Thanks, Anthony. The light came on after I saw Richard's reply. Are the onSucceeded, onFailed methods of Tasks executed on the Application thread or do I need to call runLater?
>> Mark
>> On Apr 2, 2013 1:18 AM, "Anthony Petrov" <anthony.petrov at oracle.com <mailto:anthony.petrov at oracle.com>> wrote:
>>    Platform#runLater is not a general purpose mechanism to execute
>>    deferred tasks. Its purpose is to schedule execution of runnables on
>>    the event thread in order to perform GUI-related operations. As
>>    Richard says, the event thread is a native GUI thread. There's only
>>    one such thread per application, hence the design of this machinery.
>>    Note that running code that is unrelated to GUI on the event thread
>>    may only make your application UI more sluggish and jerky, or even
>>    appearing frozen sometimes.
>>    If you need to execute general-purpose tasks asynchronously, you
>>    have to create an executor service instance (such as a ForkJoinPool)
>>    yourself and submit your runnables there.
>>    --
>>    best regards,
>>    Anthony
>>    On 4/1/2013 23:05, Mark Fortner wrote:
>>        In the past, I've found the *Platform#runLater* method to be a
>>        useful way
>>        to run tasks. However, I've noticed that the code that runs my
>>        thread is
>>        not really configurable or accessible.  For example, it would be
>>        nice to be
>>        able to specify and configure a top-level *ThreadPoolExecutor*
>>        to handle my
>>        tasks.  Or be able to switch out *Executor* implementations.
>>        I was wondering if there was some reason for implementing
>>        runLater this
>>        way, or if there are any plans to change it in the future?
>>        Cheers,
>>        Mark