When I worked on NetBeans, we used to joke that SwingUtilities.invokeAndWait() should have been named invokeAndDeadlock() (and nobody who used it outside a unit test would get it past a code review). This is the same case, just in JavaFX.
The bottom line on this has nothing to do with Guice. GUI toolkits have locks - lots of them, and frequently one big one for mutating on-screen state. The locks GUI component code acquires can change across revisions of the toolkit. If you want to block a background thread waiting for something to happen on the dispatch thread, and there is *any possibility *that your background thread will be holding any locks at all, your code will be deadlock-prone, and even "looks like it works" code may deadlock when run against some future version of the toolkit. The only way to win that game is not to play. The invokeAndWait() pattern is dangerous, and there is provably no way to make it safe. You might be able to get out of your current dilemma by constructing your singleton eagerly on startup before any GUI code runs or the event loop is even initialized. But really, if you don't want to be chasing heisenbugs for eternity, you need to stop using the invokeAndWait() pattern and find a design that doesn't require it (hint: learn to love callbacks, and do the post-wait work there). -Tim -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-guice+unsubscr...@googlegroups.com. To post to this group, send email to google-guice@googlegroups.com. Visit this group at https://groups.google.com/group/google-guice. To view this discussion on the web visit https://groups.google.com/d/msgid/google-guice/30e7fa23-6572-4875-af9c-e4fbd560ae73%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
