launching JavaFX in 11

[Johan Vos]

I fully agree with you the way forward is using named modules. The reason I
ran into this issue was that I wanted to create a regression test: it
should not work if the modules are not on the module-path. And
surprisingly, it did work.

The current check in the Launcher is hiding potential issues. It will only
check for a valid javafx.graphics module in case the supplied main class
extends javafx.application.Application.

This is something maven circumvents by default by using its own main class
when starting the VM (rather then spawning a new process). As maven is
probably the most commonly used tool for application development, this
means by default the check in the Launcher won't work.

I'm not worried about getting the named modules published, but my main
worry is that tools like maven (I still have to check gradle 4.8) by
default don't leverage modules. However, this might be more relevant on the
jigsaw list?

- Johan




On Tue, Jun 5, 2018 at 7:26 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Hi Johan,
>
> The intention is to launch using --module-path
>
>      java --module-path path-to-sdk/javafx-sdk-11/lib ...
>
> For non-modular applications you also need to add the modules to the
> module graph, for example:
>
>      java --module-path path-to-sdk/javafx-sdk-11/lib --add-modules
> javafx.fxml,javafx.controls ...
>
> You say that running an app from maven works fine. Have you verified
> that the jar files you publish to Maven include a module-info.class file
> in each modular jar?
>
> I suspect that many things could be made to work with javafx modules on
> the classpath instead of the module path, but I don't really recommend
> that. I suspect there will be a few things that won't work without some
> modifications. I think effort would be better spent getting everything
> to work with javafx.* modules as proper named modules.
>
> -- Kevin
>
>
> On 6/5/2018 6:40 AM, Johan Vos wrote:
> > Hi,
> >
> > I'm a bit confused on the different options for launching JavaFX
> > applications with the latest Java 11 code.
> > When running an app from maven, it worked fine. Maven uses the classpath
> > and not the module path, so I assumed that running the same app using
> >
> > java -cp all-javafx-jars Main
> >
> > would work too. But it doesn't. The error I got is this:
> >
> > Error: JavaFX runtime components are missing, and are required to run
> this
> > application
> >
> > This error comes from sun.launcher.LauncherHelper in the java.base
> module.
> > The reason for this is that the Main app extends Application and has a
> main
> > method. If that is the case, the LauncherHelper will check for the
> > javafx.graphics module to be present as a named module:
> >
> > Optional<Module> om =
> > ModuleLayer.boot().findModule(JAVAFX_GRAPHICS_MODULE_NAME);
> >
> > If that module is not present, the launch is aborted.
> > Hence, having the JavaFX libraries as jars on the classpath is not
> allowed
> > in this case.
> >
> > Fair, but that doesn't explain why it works via maven. The reason is that
> > maven doesn't start a new VM process, hence the main class is in this
> > case  org.codehaus.plexus.classworlds.launcher.Launcher which does not
> > extend Application, hence it doesn't do the check on javafx.graphics
> module
> > to be present as a named module, and when the required jars (including
> > native code) are on the classpath, it works fine.
> >
> > I thought the check on the main class extending
> > javafx.application.Application was removed from the core JDK, but it is
> > still there, so I understand why it works using maven and fails using a
> > standalone java invocation.
> >
> > While I fully agree the goal is to have the JavaFX modules as named
> modules
> > on the module path, I think this will create confusion. A simple
> workaround
> > is to have a separate main class that doesn't extend Application, but
> that
> > seems a real dirty solution.
> >
> > But maybe I'm missing something?
> >
> > - Johan
>
>