Platform#runLater Question

[Daniel Zwolenski]

Just on the topic, I've had situations where I've wanted Tasks (and
Services) to run in my own threading model (e.g. for unit testing). So I've
had similar wants to Mark's original request (but not directly with
Platform.runLater, though that may also be useful).

It would be nice if the Task API was really just a way of saying what I
want done at each stage (i.e. doThisStuffBefore, doTaskStuff,
doThisStuffAfter), then I could/should be able to call those methods
directly myself from my own execution framework that may or may not be FX
related or even thread related (in much the same way Runnable doesnt
necessairly have anything to do with Threads).

>From memory this wasnt (cleanly/easily) achievable because of the tight
interdependency between Tasks and the FX threading model and property
change events, etc.

A couple of use cases:

   - unit or integration testing, where I want to make sure certain
   things/tasks happen in a certain sequence.
   - reusing tasks (particularly the background bit of them) outside of JFX
   eg. reuse of REST style calls in an Android, Swing, Command line, GWT, or
   AJAX based app (Java compiled to JScript).











On Tue, Apr 2, 2013 at 10:27 AM, Richard Bair <richard.bair at oracle.com>wrote:

> 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
>
>