Hard to say what's going on without more information. What are the JVM
args you use for launching? Are the JavaFX modules jlink'ed into the JDK
or loaded via --module-path? As a debugging aid, you might try setting
the system property "javafx.verbose" to "true" before loading your
MyApplication class.
-- Kevin
On 1/19/2022 9:40 AM, Steve Hannah wrote:
The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only
when I try to launch the JVM from a custom C launcher using JNI. It does
not occur when launching the JVM as a separate process using the "java"
binary. It also does not occur on MacOS when using the same C launcher
using JNI.
When I call MyApplication.launch(args). (where MyApplication extends the
JavaFX Application class), I get the following stack trace:
Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup
Exception in thread "Thread-5" java.lang.IllegalStateException: This
operation is permitted on the event thread only; currentThread =
Thread-5
at com.sun.glass.ui.Application.checkEventThread(Application.java:447)
at com.sun.glass.ui.Application.setName(Application.java:200)
at
com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
Exception in Application start method
Exception in thread "Thread-31" Failed to show docs
java.lang.IllegalStateException: Not on FX application thread;
currentThread = Thread-31
at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
at
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
at
com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828)
at
com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624)
at
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
java.lang.RuntimeException: Exception in Application start method
at
com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901)
at
com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.IllegalStateException: Not on FX application
thread; currentThread = Thread-6
at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295)
at
com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458)
at javafx.stage.Stage.<init>(Stage.java:254)
at javafx.stage.Stage.<init>(Stage.java:240)
at
com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845)
at
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456)
at
com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96)
I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1),
running on a few different JDK installs (all JDK11). Above stacktrace is
from 17.0.1.
From the C application that launches the JVM, I have tried running directly
on the main thread, and also launching it in a fresh thread using pthreads
- but same issue. I am running this inside an application written in Go
but the JNI code is all in C.
It appears as though JavaFX is unable to create its application thread for
some reason. Does anyone have any suggestions on reasons why this would be
the case? Are there some system properties that need to be there which
would have been bootstrapped by the "java" binary, but would not when the
JVM is launched via JNI?
Any suggestions appreciated. I've been banging my head on this for a while
now.
Best regards
Steve
