JavaFX 9: Expose PlatformImpl.runAndWait() as Platform.runAndWait()

[Tom Schindl]

e(fx)clipse also uses FutureTask - we initially used CountDownLatch but it escapes my mind what was the reason for that change.

BTW: We have many other clever util methods in this area - see 
- http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.ui.workbench.fx/src/org/eclipse/fx/ui/workbench/fx/internal/UISynchronizeImpl.java
- http://git.eclipse.org/c/efxclipse/org.eclipse.efxclipse.git/tree/bundles/runtime/org.eclipse.fx.core/src/org/eclipse/fx/core/ThreadSynchronize.java

Tom

Von meinem iPhone gesendet

> Am 03.11.2016 um 00:23 schrieb Herve Girod <herve.girod at gmail.com>:
> 
> We have a use case where we receive a LOT of processing orders in one
> Thread in a TCP socket and we have to perform the drawing in the JavaFX
> Thread, but also we must wait until the effective drawing has finished
> before ordering a new drawing (because otherwise some parameters could have
> changed in the middle of the drawing so the rsulting image could be
> inconsistent). We use Platform.runLater with a future in our case like:
>         FutureTask<?> future = new FutureTask<>(runnable, null);
>         Platform.runLater(future);
>         try {
>            future.get();
>            return true;
>         } catch...
> 
> I don't know if this is a valid pattern. Of course the Thread which handle
> this code has to be different from the Thread which handle the socket
> reception in our case.
> 
> Hervé
> 
> 2016-11-02 22:13 GMT+01:00 Kevin Rushforth <kevin.rushforth at oracle.com>:
> 
>> We use runAndWait (using a CountDownLatch) in many of our unit tests. You
>> might take a look at:
>> 
>> tests/system/src/test/java/test/util/Util.java
>> 
>> Its runAndWait method also handles propagating runtime exceptions and
>> errors (e.g., assertion failures) from the body of the runAndWait back to
>> the caller.
>> 
>> -- Kevin
>> 
>> 
>> Benjamin Gudehus wrote:
>> 
>>> I wonder, if it is possible to test JavaFX applications without blocking
>>> the main thread. User interactions could be completely simulated by using
>>> Event.fireEvent(...) and we could enqueue assertions in the JavaFX
>>> application thread, in which case the assertion library needs to support
>>> asynchronous assertions.
>>> 
>>> On Wed, Nov 2, 2016 at 9:02 PM, Stefan Fuchs <snfuchs at gmx.de <mailto:
>>> snfuchs at gmx.de>> wrote:
>>> 
>>>    Hi,
>>> 
>>>    in my experience blocking your working thread for the JavaFX
>>>    application thread is almost always a sign of bad application design.
>>>    You can easily deadlock your application. In our quite complex
>>>    JavaFX Application, we could eliminate almost all of its uses.
>>> 
>>>    However, in one case it is still needed: In a thread we
>>>    sequentially prepare several images in the background, create a
>>>    snapshot and save them as jpegs.
>>>    Here we use java.util.concurrent.CountDownLatch to simulate
>>>    PlatformImpl.runAndWait.
>>> 
>>>            final WritableImage image = new WritableImage((int)
>>>    targetWidth, (int) targetHeight);
>>>            final CountDownLatch countDownLatch = new CountDownLatch(1);
>>>            Platform.runLater(() -> {
>>> 
>>>                     /* render  and snapshot image */
>>> 
>>>                     countDownLatch.countDown();
>>>             });
>>> 
>>>            boolean released = countDownLatch.await(10, TimeUnit.SECONDS);
>>>            if (!released) {
>>>                Logger.getLogger(getClass()).error("Timeout reached,
>>>    while waiting for snapshot");
>>>                return null;
>>>            }
>>> 
>>>            return image;
>>> 
>>> 
>>> 
>>>    What I would like to see implemented is a method, we call
>>>    runNowOrLater.
>>> 
>>>    That is, if I'm on the JavaFX ApplicationThread execute the
>>>    Runnable immediately, if not call Platform.runLater().
>>>    With this method I have not to worry, if I'm on the JavaFX
>>>    Application thread or not and I avoid flooding the event queue
>>>    with calls to Platform.runLater, that could have been executed
>>>    directly.
>>> 
>>>    So basically:
>>> 
>>>        public static void runNowOrLater(final Runnable runnable) {
>>>            if (Platform.isFxApplicationThread()) {
>>>                runnable.run();
>>>            } else {
>>>                Platform.runLater(runnable);
>>>            }
>>>        }
>>> 
>>>    -- Stefan
>>> 
>>> 
>>> 
>>> 
>>>        Hi, Kevin. Thanks for the info!
>>> 
>>>        On Wed, Nov 2, 2016 at 5:36 PM, Kevin Rushforth
>>>        <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>>
>>>        wrote:
>>> 
>>>            No. This isn't something we will do for JDK 9, which is
>>>            feature complete
>>>            (with an exception process for critical requests,
>>>            especially relating to
>>>            Jigsaw). I note in this case that it isn't clear whether
>>>            we want to do this
>>>            one at all.
>>> 
>>>            -- Kevin
>>> 
>>> 
>>> 
>>>            Benjamin Gudehus wrote:
>>> 
>>>                Hey!
>>> 
>>>                Are there plans to expose this API [1] in JavaFX 9?
>>> 
>>>                // NOTE: Add the following if we decide to expose it
>>>                publicly
>>>                // public static void runAndWait(Runnable runnable) {
>>>                // PlatformImpl.runAndWait(runnable);
>>>                // }
>>> 
>>>                [1] http://hg.openjdk.java.net/openjfx/9-dev/rt/file/
>>>                <http://hg.openjdk.java.net/openjfx/9-dev/rt/file/>
>>>                6edd0c3c01f4/modules/javafx.gr
>>>                <http://javafx.gr>aphics/src/main/java/javafx/
>>>                application/Platform.java#l148
>>> 
>>>                --Benjamin
>>> 
>>> 
>>> 
>>> 
>>>