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.gi...@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.rushfo...@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 <snfu...@gmx.de <mailto: >>> snfu...@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.rushfo...@oracle.com <mailto:kevin.rushfo...@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 >>> >>> >>> >>> >>>
