-
Enhancement
-
Resolution: Fixed
-
P3
-
8
Currently, an FX application is loaded and constructed on a background thread rather than the FX application thread. The init() method is also called on a background thread.
We may want to consider changing the specification and implementation of the JavaFX launcher, for both standalone applications and for JNLP applications / applets, so that the Application is loaded and constructed in the FX application thread. The init() method should still be called on a background thread. We would need to do this is such a way that performance is not impacted. In particular we need to ensure that an application can still be initialized in parallel via the init() method while a preloader is running.
See the discussion inRT-28574 for more background information.
Quoting Richard from that JIRA:
"the platform will be easier to understand and the behavior more predictable if the developer is not exposed to multiple threads unless they take action to do so. Simplifying life for developers is A Good Thing (tm), and reducing bugs they might encounter even better. Not to mention the bugs we will encounter in our own platform!
Simple example, creating a Scene in the constructor or as a field on the class. A major no-no today (even though there is no reason we shouldn't allow scene creation on a background thread. Heck, you should be able to create a Stage on a background thread, as long as you don't try to show it)."
We may want to consider changing the specification and implementation of the JavaFX launcher, for both standalone applications and for JNLP applications / applets, so that the Application is loaded and constructed in the FX application thread. The init() method should still be called on a background thread. We would need to do this is such a way that performance is not impacted. In particular we need to ensure that an application can still be initialized in parallel via the init() method while a preloader is running.
See the discussion in
Quoting Richard from that JIRA:
"the platform will be easier to understand and the behavior more predictable if the developer is not exposed to multiple threads unless they take action to do so. Simplifying life for developers is A Good Thing (tm), and reducing bugs they might encounter even better. Not to mention the bugs we will encounter in our own platform!
Simple example, creating a Scene in the constructor or as a field on the class. A major no-no today (even though there is no reason we shouldn't allow scene creation on a background thread. Heck, you should be able to create a Stage on a background thread, as long as you don't try to show it)."
- duplicates
-
JDK-8123255 static block setDefaultPlatformUserAgentStylesheet() in PlatformImpl causes IllegalStateException
-
- Closed
-
- relates to
-
JDK-8087496 [IntelliJ] JavaFX application not initialized on FX app thread
-
- Open
-
-
JDK-8095280 Thread classloader gets lost through the JFX launch process
-
- Resolved
-
-
JDK-8124368 Problems with Application static objects and pipeline initialization
-
- Resolved
-