I do hope we do keep allowing launching without module path, as that makes debugging problems a lot easier (I can override JavaFX classes by just copy/pasting them into the project, and trying fixes or adding debug logs).
--John On 10/04/2026 07:51, Christopher Schnick wrote: > Yes, I was testing the launch without a module path. > > The minimal improvement would be to fix the error message, because it > is wrong. The runtime components are there, they are just not > correctly configured with a module path. > > Alternatively, I think this specific abort() call could also be > removed from the JDK code as JavaFX itself will also print its own > warning in this case. > > On 10/04/2026 01:02, Kevin Rushforth wrote: >> This is intentional and is still useful to allow launching JavaFX >> applications that don't have a main program. It also ensures that the >> JavaFX runtime is launched before the main program runs if there is a >> main program. >> >> How are you launching your app that you are running into this? If the >> JavaFX modules are on the module path the Java launcher should find >> it. If the JavaFX modules are NOT on the module path, but instead on >> the classpath, then that is an unsupported mode. You may run into >> other problems in that mode, but this is the most noticeable one. >> >> -- Kevin >> >> >> On 4/9/2026 7:37 AM, Christopher Schnick wrote: >>> I was just playing around with the launch process for JavaFX and >>> encountered the known issue "JavaFX runtime components are missing, >>> and are required to run this application" when the Main class >>> extends Application. >>> >>> Then, I wanted to look where this message is printed from and how >>> the launch process is handled to see if there are possible >>> improvements there. >>> >>> Now if I see this correctly, the non-modular JavaFX Application >>> launching is done from the JDK itself? The code is still included in >>> the JDK in java.base at sun.launcher.LauncherHelper.FXHelper and not >>> decoupled from the JDK. So this can't even be changed in the jfx >>> codebase. >>> >>> Is this intentional or a leftover, i.e. would it be possible to even >>> change this or is that some legacy thing which can't be changed? >>> >>
