Why does Platform.runLater not check if it currently is on the JavaFX thread?

Question

When using JavaFX 8, we need to run interactions with the GUI via Platform.runLater, or else they will throw exceptions if ran from another thread.

However the implementation of Platform.runLater never checks whether it currently is on the JavaFX thread.

I wrote the following method:

public static void runSafe(final Runnable runnable) {
    Objects.requireNonNull(runnable, "runnable");
    if (Platform.isFxApplicationThread()) {
        runnable.run();
    }
    else {
        Platform.runLater(runnable);
    }
}

This ensures that it can never be run on a non-fx-application thread.

Is there any reason that the default implementation does not do this kind of short-circuiting?

Nice to see good questions with good answers on StackOverflow. — jewelsea, Jun 04 '14 at 18:39
I wish this method would be added to `Platform`, because that's what I'm looking for in 90% of the cases. — Stefan Endrullis, Oct 17 '18 at 13:35

score 18 · Accepted Answer · answered Jun 04 '14 at 17:22

18

runLater essentially places your Runnable in a queue for execution when the FX thread is available. The method can be accessed through non-FX threads. Imagine that some other threads have placed tasks in the runLater queue, then calling runLater again, whether from the FX thread or not, should place the new task at the tail of that queue.

With the short-circuiting you propose the previous tasks would basically have a lower priority which may not be desirable.

answered Jun 04 '14 at 17:22

assylias

321,522
82
660
783

In general I agree this is a side effect of any runLater however it is bad by design. The OP is right in his consideration but unfortunately it works like this. – Thomas Mar 23 '23 at 11:13

rolfl · Answer 2 · 2014-06-04T17:43:01.127

When calling a function, and the function is called 'runLater', I would expect it to be run later, not now.

It seems to me that the implementation is doing the right thing, based on it's name, and it's documentation:

Run the specified Runnable on the JavaFX Application Thread at some unspecified time in the future.

This method, which may be called from any thread, will post the Runnable to an event queue and then return immediately to the caller. The Runnables are executed in the order they are posted. A runnable passed into the runLater method will be executed before any Runnable passed into a subsequent call to runLater

If you don't want the code to run later, don't ask for it to be run later. That is what you have essentially done with your code.

score 0 · Answer 3 · edited May 23 '17 at 11:46

I've seen people calling EventQueue.invokeLater from the EDT in Swing occasionally... it is, according to canon, a legitimate technique. So this is the same situation in JavaFX, unless I'm much mistaken.

I personally have my doubts about this technique, however. See this question: the chosen answer uses invokeLater because selectAll() needs to have all the current EDT events complete themselves before it is called: this solution does indeed ensure that selectAll cannot be run before the other EDT code happening here.

But this answer, I maintain, has vulnerabilities. See the answer I have suggested (written in Jython, but should be understandable). Suppose someone sets "click count to start editing" to 1. Suppose, more worringly, something unpredictable happens between the invokeLater and the selectAll. Unless you are absolutely sure you have no alternative mechanism at all, or are absolutely sure that the events and objects of the two threads are completely "uncoupled", I personally would say avoid calling runLater from the JavaFX thread.

Concurrency is always waiting to bite you. Best use such techniques with extreme caution, therefore!

Why does Platform.runLater not check if it currently is on the JavaFX thread?

3 Answers3