Graal: JavaFX native image hangs and doesn't show any window

[cubuspl42]

I succeeded to build and run a JavaFX native image. It required some patching.

(details: https://github.com/cubuspl42/JavaFX-Graal-HelloWorld)

The program hangs before it shows any window:

➜  JavaFX-Graal-HelloWorld git:(master) ✗ ./helloworld -Dprism.verbose=true -Djava.library.path=$JAVA_HOME/jre/lib
Prism pipeline init order: es2 sw
Using native-based Pisces rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
(X) Got class = class com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2
    succeeded.
GLFactory using com.sun.prism.es2.MacGLFactory
Initialized prism pipeline: com.sun.prism.es2.ES2Pipeline

Do you have any idea what might be the reason, or how to debug it?

[johanvos]

From your code, it looks like you're running on Mac.

One of the changes you have to make on Mac is to get out of the main thread, so that Glass can call a selector that runs on the main thread (e.g. see https://bitbucket.org/javafxports/8u-dev-rt/src/1337673d0693dc7cee6e135d76fa47f06487a0aa/modules/graphics/src/main/native-glass/mac/GlassApplication.m?at=jvmci&fileviewer=file-view-default#GlassApplication.m-866)

If you don't do this, you will get stuck when starting the JavaFX Application thread (which needs to run on the main UI thread) (You can add some debug info in your Application.java to make sure this is where your app gets stuck.)

I do this by creating a small launcher.m file that starts the UI and in the callback method the JavaFX app can be started. That launcher can be linked with the objectfile created by SVM into an executable.

[cubuspl42]

@johanvos Thank you for your response!

So it sounds that you've managed to successfully run a JavaFX app on Graal / native image, is it correct? Did you also have to go through all the issues I listed in the readme, or did I do something wrong? Is the project you mentioned (the one with launcher.m) open source?

[johanvos]

Yes, I had a JavaFX 8 running on SVM, and ran indeed in those issues. I also modified a number of JavaFX class initialisers to take advantage of executing clinit functions at build time.
My goal is that all JavaFX apps should run easily on SVM, so it should all be open source.

[cubuspl42]

So does that link you posted before point to the fork with the mentioned changes? I'm sorry, I'm just trying to figure out what's the current status of Graal+JavaFX. It's not really obvious.

[johanvos]

That is a fork but it won't be maintained as it was just a POC to see if/how JavaFX 8 worked on SVM. It was a positive experience, so focus is now on JavaFX 11 and beyond.
The goal is to have all required changes in JavaFX being upstreamed, for now I use a branch in my fork at https://github.com/johanvos/openjdk-jfx/tree/jfx-11-svm .
I try to leverage as much class initialisation at build time as possible, as that really makes a huge difference in performance. It has some serious consequences for JavaFX, but we will deal with those once we have something working using JavaFX 11+

[maxum2610]

I created an example on labsjdk1.8.0_192-jvmci-0.53 and graal/svm rc14 using Johans simplesvm example and cubuspl42's build script here:
https://github.com/maxum2610/HelloJFX-GraalSVM

[cstancu]

As reported by https://github.com/oracle/graal/issues/403#issuecomment-559213856 it is now possible to create native executables for JavaFX applications on Linux, MacOS and iOS. I am closing this issue, please open a new one if you run into further issues.