Graal: [native-image] Native image of JavaFX application can not run

[Glavo]

I'm trying to use GraalVM EE and GraalVM CE with OpenJFX installed to generate a native image for ClassViewer, but they could not operate properly for different reasons

GraalVM CE with OpenJDK:

glavo@glavo:~/下载$ ./graalvm-1.0.0-rc1/bin/native-image -jar ClassViewer-3.2.jar 
Warning: Native image server limit exceeded. Use options --server{-list,-shutdown[-all]} to fix the problem.
   classlist:   1,028.48 ms
       (cap):   1,500.51 ms
       setup:   2,462.52 ms
[INFO] Load recent files from file: /home/glavo/.viewer/recentfiles
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
    at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:221)
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:248)
    at javafx.scene.image.Image.loadImage(Image.java:1065)
    at javafx.scene.image.Image.initialize(Image.java:807)
    at javafx.scene.image.Image.<init>(Image.java:621)
    at org.glavo.viewer.util.ImageUtils.loadImage(ImageUtils.java:19)
    at org.glavo.viewer.util.ImageUtils.<clinit>(ImageUtils.java:30)
    at org.glavo.viewer.gui.filetypes.classfile.ClassFileType.<init>(ClassFileType.java:24)
    at org.glavo.viewer.gui.filetypes.classfile.ClassFileType.<clinit>(ClassFileType.java:20)
    at org.glavo.viewer.gui.filetypes.FileType.<clinit>(FileType.java:17)
    at org.glavo.viewer.gui.RecentFile.parse(RecentFile.java:14)
    at org.glavo.viewer.gui.RecentFiles.lambda$load$1(RecentFiles.java:127)
    at java.util.Iterator.forEachRemaining(Iterator.java:116)
    at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
    at org.glavo.viewer.gui.RecentFiles.load(RecentFiles.java:124)
    at org.glavo.viewer.gui.RecentFiles.<init>(RecentFiles.java:28)
    at org.glavo.viewer.gui.RecentFiles.<clinit>(RecentFiles.java:19)
    at sun.misc.Unsafe.ensureClassInitialized(Native Method)
    at jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:695)
    at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(WrappedConstantPool.java:58)
    at org.graalvm.compiler.java.BytecodeParser.maybeEagerlyResolve(BytecodeParser.java:3847)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.maybeEagerlyResolve(SharedGraphBuilderPhase.java:102)
    at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3801)
    at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1380)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:171)
    at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4677)
    at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3065)
    at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2886)
    at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:880)
    at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:774)
    at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:93)
    at org.graalvm.compiler.phases.Phase.run(Phase.java:47)
    at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:195)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:40)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:36)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:195)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:319)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.StaticInvokeTypeFlow.update(InvokeTypeFlow.java:344)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.lang.Thread.run(Thread.java:748)
Graphics Device initialization failed for :  es2, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
    at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:221)
    at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:248)
    at javafx.stage.Screen.<clinit>(Screen.java:79)
    at sun.misc.Unsafe.ensureClassInitialized(Native Method)
    at jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:695)
    at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(WrappedConstantPool.java:58)
    at org.graalvm.compiler.java.BytecodeParser.maybeEagerlyResolve(BytecodeParser.java:3847)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.maybeEagerlyResolve(SharedGraphBuilderPhase.java:102)
    at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3801)
    at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1380)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:171)
    at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4677)
    at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3065)
    at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2886)
    at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:880)
    at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:774)
    at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:93)
    at org.graalvm.compiler.phases.Phase.run(Phase.java:47)
    at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:195)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:40)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:36)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:195)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:319)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.SpecialInvokeTypeFlow.onObservedUpdate(InvokeTypeFlow.java:419)
    at com.oracle.graal.pointsto.flow.TypeFlow.notifyObservers(TypeFlow.java:345)
    at com.oracle.graal.pointsto.flow.TypeFlow.update(TypeFlow.java:387)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
    at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
    at java.lang.Thread.run(Thread.java:748)

GraalVM EE:

glavo@glavo:~/下载/A$ ./graalvm-1.0.0-rc1/bin/native-image -jar ClassViewer-3.2.jar 
Warning: Native image server limit exceeded. Use options --server{-list,-shutdown[-all]} to fix the problem.
   classlist:   1,110.72 ms
       (cap):   2,017.22 ms
       setup:   3,309.41 ms
[INFO] Load recent files from file: /home/glavo/.viewer/recentfiles
    analysis:   7,225.19 ms
error: unsupported features in 7 methods
Detailed message:
Error: Error loading a referenced type: java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = ForkJoinPool-3-worker-7
Trace: 
    at parsing javafx.stage.Window.<init>(Window.java:1209)
Call path from entry point to javafx.stage.Window.<init>(): 
    at javafx.stage.Window.<init>(Window.java:155)
    at javafx.stage.Stage.<init>(Stage.java:239)
    at javafx.stage.Stage.<init>(Stage.java:227)
    at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$159(LauncherImpl.java:783)
    at com.sun.javafx.application.LauncherImpl$$Lambda$511/494541179.run(Unknown Source)
    at com.oracle.svm.core.JavaMainWrapper$JavaMainSupport.executeHooks(JavaMainWrapper.java:105)
    at com.oracle.svm.core.JavaMainWrapper$JavaMainSupport.executeStartupHooks(JavaMainWrapper.java:91)
    at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:198)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)
Original exception that caused the problem: java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = ForkJoinPool-3-worker-7
    at com.sun.glass.ui.Application.checkEventThread(Application.java:443)
    at com.sun.glass.ui.Screen.setEventHandler(Screen.java:285)
    at com.sun.javafx.tk.quantum.QuantumToolkit.setScreenConfigurationListener(QuantumToolkit.java:674)
    at javafx.stage.Screen.<clinit>(Screen.java:79)
    at sun.misc.Unsafe.ensureClassInitialized(Native Method)
    at jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:695)
    at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(WrappedConstantPool.java:58)
    at org.graalvm.compiler.java.BytecodeParser.maybeEagerlyResolve(BytecodeParser.java:3847)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.maybeEagerlyResolve(SharedGraphBuilderPhase.java:102)
    at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3801)
    at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1380)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:171)
    at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4677)
    at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3065)
    at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2886)
    at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:880)
    at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:774)
    at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:93)
    at org.graalvm.compiler.phases.Phase.run(Phase.java:47)
    at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:195)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:40)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:36)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:195)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:319)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.SpecialInvokeTypeFlow.onObservedUpdate(InvokeTypeFlow.java:419)
    at com.oracle.graal.pointsto.flow.TypeFlow.notifyObservers(TypeFlow.java:345)
    at com.oracle.graal.pointsto.flow.TypeFlow.update(TypeFlow.java:387)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Error: Error loading a referenced type: java.lang.NoClassDefFoundError: Could not initialize class javafx.stage.Screen
Trace: 
    at parsing com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298)
Call path from entry point to com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(): 
    at com.sun.javafx.tk.quantum.QuantumToolkit.initSceneGraph(QuantumToolkit.java:298)
    at com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:340)
    at com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$402(QuantumToolkit.java:257)
    at com.sun.javafx.tk.quantum.QuantumToolkit$$Lambda$538/1806242102.run(Unknown Source)
    at com.oracle.svm.core.JavaMainWrapper$JavaMainSupport.executeHooks(JavaMainWrapper.java:105)
    at com.oracle.svm.core.JavaMainWrapper$JavaMainSupport.executeStartupHooks(JavaMainWrapper.java:91)
    at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:198)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)
Original exception that caused the problem: java.lang.NoClassDefFoundError: Could not initialize class javafx.stage.Screen
    at sun.misc.Unsafe.ensureClassInitialized(Native Method)
    at jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:695)
    at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(WrappedConstantPool.java:58)
    at org.graalvm.compiler.java.BytecodeParser.maybeEagerlyResolve(BytecodeParser.java:3847)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.maybeEagerlyResolve(SharedGraphBuilderPhase.java:102)
    at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3801)
    at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1380)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:171)
    at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4677)
    at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3065)
    at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2886)
    at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:880)
    at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:774)
    at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:93)
    at org.graalvm.compiler.phases.Phase.run(Phase.java:47)
    at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:195)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:40)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:36)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:195)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:319)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.StaticInvokeTypeFlow.update(InvokeTypeFlow.java:344)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Error: Error loading a referenced type: java.lang.RuntimeException: Internal graphics not initialized yet
Trace: 
    at parsing org.glavo.viewer.gui.Options.init(Options.java:51)
Call path from entry point to org.glavo.viewer.gui.Options.init(): 
    at org.glavo.viewer.gui.Options.init(Options.java:25)
    at org.glavo.viewer.gui.Viewer.main(Viewer.java:28)
    at com.oracle.svm.reflect.proxies.Proxy_1_Viewer_main.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:199)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eJavaMainWrapper_002erun_0028int_002corg_002egraalvm_002enativeimage_002ec_002etype_002eCCharPointerPointer_0029(generated:0)
Original exception that caused the problem: java.lang.RuntimeException: Internal graphics not initialized yet
    at com.sun.glass.ui.Screen.getScreens(Screen.java:70)
    at com.sun.javafx.tk.quantum.QuantumToolkit.getScreens(QuantumToolkit.java:699)
    at com.sun.javafx.tk.quantum.QuantumToolkit.getMaxRenderScale(QuantumToolkit.java:719)
    at com.sun.javafx.tk.quantum.QuantumToolkit.loadImage(QuantumToolkit.java:727)
    at javafx.scene.image.Image.loadImage(Image.java:1065)
    at javafx.scene.image.Image.initialize(Image.java:807)
    at javafx.scene.image.Image.<init>(Image.java:621)
    at org.glavo.viewer.util.ImageUtils.loadImage(ImageUtils.java:19)
    at org.glavo.viewer.util.ImageUtils.<clinit>(ImageUtils.java:30)
    at org.glavo.viewer.gui.filetypes.classfile.ClassFileType.<init>(ClassFileType.java:24)
    at org.glavo.viewer.gui.filetypes.classfile.ClassFileType.<clinit>(ClassFileType.java:20)
    at org.glavo.viewer.gui.filetypes.FileType.<clinit>(FileType.java:17)
    at org.glavo.viewer.gui.RecentFile.parse(RecentFile.java:14)
    at org.glavo.viewer.gui.RecentFiles.lambda$load$1(RecentFiles.java:127)
    at java.util.Iterator.forEachRemaining(Iterator.java:116)
    at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
    at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
    at org.glavo.viewer.gui.RecentFiles.load(RecentFiles.java:124)
    at org.glavo.viewer.gui.RecentFiles.<init>(RecentFiles.java:28)
    at org.glavo.viewer.gui.RecentFiles.<clinit>(RecentFiles.java:19)
    at sun.misc.Unsafe.ensureClassInitialized(Native Method)
    at jdk.vm.ci.hotspot.HotSpotConstantPool.loadReferencedType(HotSpotConstantPool.java:695)
    at com.oracle.graal.pointsto.infrastructure.WrappedConstantPool.loadReferencedType(WrappedConstantPool.java:58)
    at org.graalvm.compiler.java.BytecodeParser.maybeEagerlyResolve(BytecodeParser.java:3847)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.maybeEagerlyResolve(SharedGraphBuilderPhase.java:102)
    at org.graalvm.compiler.java.BytecodeParser.lookupMethod(BytecodeParser.java:3801)
    at org.graalvm.compiler.java.BytecodeParser.genInvokeStatic(BytecodeParser.java:1380)
    at com.oracle.svm.hosted.phases.SharedGraphBuilderPhase$SharedBytecodeParser.genInvokeStatic(SharedGraphBuilderPhase.java:171)
    at org.graalvm.compiler.java.BytecodeParser.processBytecode(BytecodeParser.java:4677)
    at org.graalvm.compiler.java.BytecodeParser.iterateBytecodesForBlock(BytecodeParser.java:3065)
    at org.graalvm.compiler.java.BytecodeParser.processBlock(BytecodeParser.java:2886)
    at org.graalvm.compiler.java.BytecodeParser.build(BytecodeParser.java:880)
    at org.graalvm.compiler.java.BytecodeParser.buildRootMethod(BytecodeParser.java:774)
    at org.graalvm.compiler.java.GraphBuilderPhase$Instance.run(GraphBuilderPhase.java:93)
    at org.graalvm.compiler.phases.Phase.run(Phase.java:47)
    at org.graalvm.compiler.phases.BasePhase.apply(BasePhase.java:195)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:40)
    at org.graalvm.compiler.phases.Phase.apply(Phase.java:36)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.parse(MethodTypeFlowBuilder.java:195)
    at com.oracle.graal.pointsto.flow.MethodTypeFlowBuilder.apply(MethodTypeFlowBuilder.java:319)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.doParse(MethodTypeFlow.java:308)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.ensureParsed(MethodTypeFlow.java:298)
    at com.oracle.graal.pointsto.flow.MethodTypeFlow.addContext(MethodTypeFlow.java:105)
    at com.oracle.graal.pointsto.flow.StaticInvokeTypeFlow.update(InvokeTypeFlow.java:344)
    at com.oracle.graal.pointsto.BigBang$2.run(BigBang.java:498)
    at com.oracle.graal.pointsto.util.CompletionExecutor.lambda$execute$0(CompletionExecutor.java:172)
    at java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1402)
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
Error: Must not have a started Thread in the image heap.
Trace:  object com.sun.javafx.tk.quantum.QuantumRenderer
    object java.util.concurrent.atomic.AtomicReference
    method com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer()
Call path from entry point to com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(): 
    at com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(QuantumRenderer.java:195)
    at com.sun.javafx.tk.quantum.QuantumToolkit.dispose(QuantumToolkit.java:781)
    at com.sun.javafx.tk.quantum.QuantumToolkit$1.run(QuantumToolkit.java:230)
    at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:222)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0)
Error: Must not have a started Thread in the image heap.
Trace:  field com.sun.prism.es2.ES2Pipeline.creator
Error: Must not have a started Thread in the image heap.
Trace:  object java.util.concurrent.ThreadPoolExecutor$Worker
    object java.util.HashMap$Node
    object java.util.HashMap$Node[]
    object java.util.HashMap
    object java.util.HashSet
    object com.sun.javafx.tk.quantum.QuantumRenderer
    object java.util.concurrent.atomic.AtomicReference
    method com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer()
Call path from entry point to com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(): 
    at com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(QuantumRenderer.java:195)
    at com.sun.javafx.tk.quantum.QuantumToolkit.dispose(QuantumToolkit.java:781)
    at com.sun.javafx.tk.quantum.QuantumToolkit$1.run(QuantumToolkit.java:230)
    at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:222)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0)
Error: Must not have a started Thread in the image heap.
Trace:  object java.util.concurrent.locks.AbstractQueuedSynchronizer$Node
    object java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
    object java.util.concurrent.LinkedBlockingQueue
    object com.sun.javafx.tk.quantum.QuantumRenderer
    object java.util.concurrent.atomic.AtomicReference
    method com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer()
Call path from entry point to com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(): 
    at com.sun.javafx.tk.quantum.QuantumRenderer.stopRenderer(QuantumRenderer.java:195)
    at com.sun.javafx.tk.quantum.QuantumToolkit.dispose(QuantumToolkit.java:781)
    at com.sun.javafx.tk.quantum.QuantumToolkit$1.run(QuantumToolkit.java:230)
    at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:222)
    at Lcom/oracle/svm/core/code/CEntryPointCallStubs;.com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_002epthreadStartRoutine_0028com_002eoracle_002esvm_002ecore_002eposix_002ethread_002ePosixJavaThreads_0024ThreadStartData_0029(generated:0)

Error: Image building with exit status 1

[Glavo]

It looks like this problem exists for all JavaFX apps GraalVM, when I tried to deal with this demo, they also failed for the same reason.

[cstancu]

@Glavo thank you for your report. We haven't tried running JavaFX apps so far. We'll look into it.

[TisonKun]

For cross refer #358

[psini]

Any news?

[alexandrenavarro]

Any news?

[ssmooncoder]

Any news?

[chengenzhao]

Any news?

[tsatatwer]

Any news please.

[chengenzhao]

Hi folks:

For JavaFX 11+, you probably don't need native image since you could use jlink to create your own customized runtime which is relatively small and JavaFX is distributed in jmods which can be used to create your own java runtime, so maybe keep a runtime is a better idea rather than compile the whole program into native:)

Hope it helps

[tsatatwer]

Compile the whole program into native in some situations protect the code speeds start up and running the program faster and reduce memory .

[Glavo]

@chengenzhao The JavaFX application I am developing is for Java developers, so I don't need to use jlink to package the entire runtime environment. My goal is to reduce the memory consumption and reduce the startup time of the application through Graal. I have tried to compile my application to native using ExcelsiorJET, and ExcelsiorJET successfully reduced 90% of startup time and 50% of memory usage.

[cubuspl42]

Managed to make it build, but doesn't run properly: https://github.com/oracle/graal/issues/994

[ssmooncoder]

Is this project dead? I guess React is the way to go for native ui...

[cubuspl42]

@ssmooncoder You must be confused, nobody ever suggested that GraalFX+JavaFX (JavaFXPorts with iOS support, I assume?...) is a production-ready solution for developing mobile applications.

[thomaswue]

@johanvos did some recent work in the area of supporting JavaFX via native images.

[tsatatwer]

@cstancu any news on the issue ???? more than ONE YEAR ???? you are looking since May 4, 2018 ??? so what now ???.

[chengenzhao]

https://gluonhq.com/a-boost-for-java-on-the-client/
beta version now
cheers

[tsatatwer]

@chengenzhao , thanks for the link BUT still only MAC NO windows yet.

[4ntoine]

any update? 1.1 year passed

[johanvos]

This is currently working on Mac, Linux and iOS. See https://github.com/gluonhq/client-samples (docs for Linux are not there yet).
We're working on Windows and Android now.

[4ntoine]

Thanks for update! Sounds great

вс, 23 Июн 2019, 22:25 Johan Vos [e-mail]:

This is currently working on Mac, Linux and iOS. See
https://github.com/gluonhq/client-samples (docs for Linux are not there
yet).
We're working on Windows and Android now.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/oracle/graal/issues/403?email_source=notifications&email_token=AAGOWT26QRL4TY4WKNGOWZDP37L2JA5CNFSM4E6L2NG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYLGJ5I#issuecomment-504784117,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAGOWT3VKWYHIB2NTYH2EHTP37L2JANCNFSM4E6L2NGQ
.

[shashaanktulsyan]

This is currently working on Mac, Linux and iOS. See https://github.com/gluonhq/client-samples (docs for Linux are not there yet).
We're working on Windows and Android now.

Thank you, looking forward to it.

[4ntoine]

Hey. I've just tried 19.1.0 with JavaFX app: https://github.com/4ntoine/NotesClientApp/

Getting the following exception:

$~/Documents/dev/src/graalvm-ce-19.1.0/Contents/Home/bin/native-image -cp /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/ext/ -jar app-javafx-all.jar 
Build on Server(pid: 68849, port: 64448)
[app-javafx-all:68849]    classlist:     702.81 ms
Fatal error: java.lang.NoClassDefFoundError: javafx/application/Application
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:348)
    at com.oracle.svm.hosted.NativeImageGeneratorRunner.buildImage(NativeImageGeneratorRunner.java:256)
    at com.oracle.svm.hosted.NativeImageGeneratorRunner.build(NativeImageGeneratorRunner.java:446)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.executeCompilation(NativeImageBuildServer.java:394)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.lambda$processCommand$8(NativeImageBuildServer.java:331)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.withJVMContext(NativeImageBuildServer.java:412)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.processCommand(NativeImageBuildServer.java:328)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.processRequest(NativeImageBuildServer.java:272)
    at com.oracle.svm.hosted.server.NativeImageBuildServer.lambda$serve$7(NativeImageBuildServer.java:232)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.ClassNotFoundException: javafx.application.Application
    at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
    ... 24 more
Error: Image build request failed with exit status 1
~/Documents/dev/src/Notes/NotesClientApp/app-javafx/build/libs asmirnov$ls /Library/Java/JavaVirtualMachines/jdk1.8.0_121.jdk/Contents/Home/jre/lib/ext/
.                   cldrdata.jar        jaccess.jar         localedata.jar      nashorn.jar         sunjce_provider.jar zipfs.jar
..                  dnsns.jar           jfxrt.jar           meta-index          sunec.jar           sunpkcs11.jar

jfxrt.jar contains javafx.application.Application

command-line seems to be correct: https://www.graalvm.org/docs/reference-manual/aot-compilation/

I can imagine some class that javafx.application.Application references can't be found..

What am i missing?

[4ntoine]

Does it require JavaFX 12 min? https://github.com/gluonhq/client-samples/blob/master/Gradle/HelloFX/build.gradle

Currently i'm trying with JavaFX8.

[Skhmt]

This is currently working on Mac, Linux and iOS. See https://github.com/gluonhq/client-samples (docs for Linux are not there yet).
We're working on Windows and Android now.

Any update on the Windows version?

[johanvos]

Does it require JavaFX 12 min? https://github.com/gluonhq/client-samples/blob/master/Gradle/HelloFX/build.gradle

Currently i'm trying with JavaFX8.

Depends on your JDK: Java 8 works with JavaFX 8, Java 11 works with JavaFX 11.

I don't work on 8 anymore, and I recommend using JavaFX 11 and beyond.

[tsatatwer]

I don't work on 8 anymore, and I recommend using JavaFX 11 and beyond.

@johanvos what is the most JDK version used?????? used and whats is the most Javafx version used??????.

[tsatatwer]

@johanvos
Java 8 is still the most dominant version of Java–almost 8 in 10 respondents say their main applications use it in production.
From : https://snyk.io/blog/jvm-ecosystem-report-2018/

[johanvos]

I don't think that discussion belongs in this issue. If you or someone else want to work on support for 8, that would be very welcome. I only work on 11 and beyond.

[tsatatwer]

@johanvos it is not a discussion it is realty.

I only work on 11 and beyond.

any way work what ever you want and like.

[bmarwell]

@johanvos that would be very sad.
Java 8 has LTS support active, offered by IBM and Oracle (and possibly others).

Also, GraalVM 1.9.11 is still java 8, isn't it?

[4ntoine]

+1 for 8 support. Since GraalVM is based on JDK8 i can see no reason javafx is supported started 11 only.

[tsatatwer]

@johanvos it is indeed relay very sad and your good efforts missed important point witch hit too many developers using Javafx as there main desktop application .

[johanvos]

JavaFX 8 LTS is closed source, and I don't have access to the sources (you have to ask Oracle or others that support it).

JavaFX 11 LTS is maintained by Gluon and the sources are available. Sources for JavaFX 12/13 and beyond are all public available as well. I can work on those.
The most important patch to JavaFX that allows it to work with GraalVM is here: https://github.com/javafxports/openjdk-jfx/commit/b109617af2803ae575f0cedc9aed6b5f12951003

JavaFX 8 is not maintained publicly anymore, so there is no way I can commit that patch somewhere in an 8 repository.

Also, based on downloads for Gluon Scene Builder, JavaFX 11 is way more downloaded than 8.

As I said, if someone wants to work on JavaFX 8 support, that would be very welcome -- although I have no idea what source repository should be used.

[chengenzhao]

JavaFX 8 LTS is closed source, and I don't have access to the sources (you have to ask Oracle or others that support it).

JavaFX 11 LTS is maintained by Gluon and the sources are available. Sources for JavaFX 12/13 and beyond are all public available as well. I can work on those.
The most important patch to JavaFX that allows it to work with GraalVM is here: javafxports/openjdk-jfx@b109617

JavaFX 8 is not maintained publicly anymore, so there is no way I can commit that patch somewhere in an 8 repository.

Also, based on downloads for Gluon Scene Builder, JavaFX 11 is way more downloaded than 8.

As I said, if someone wants to work on JavaFX 8 support, that would be very welcome -- although I have no idea what source repository should be used.

Indeed, we r using javafx 13-ea+11 to experiment new WritableImage functions to share the memory with other process.

For client side development, I think most developers would and should use bundled runtime(using jlink to create one) rather than asking users to install JVM/JDK by themselves to provide more convenient way of using our softwares.

In this way, it doesn't really matter which JDK & JavaFX version we are using, becoz the corresponding runtime is bundled for download.

And this is how we distribute our Steam games created by JavaFX

Cheers

[chengenzhao]

@johanvos that would be very sad.
Java 8 has LTS support active, offered by IBM and Oracle (and possibly others).

Also, GraalVM 1.9.11 is still java 8, isn't it?

It is Graal 19.1.1, not 1.9.11
and for aot, Gluon client side plugin is using Graal 20.x

Besides Java 8 runtime is really huge for client side softwares compared to Java 11+
It takes like about 252m(wow) for mac...
By using jlink our macrt only take 90m- only 1/3 of Java 8 runtime

[adinn]

+1 for 8 support. Since GraalVM is based on JDK8 i can see no reason javafx is supported started 11 only.

GraalVM support for jdk11 is not yet 100% complete but it is well under way. Note that JDK11 is also an LTS release.

There are several reasons why Java (OpenJDK) has moved on to JDK11 and beyond yet GraalVM is still relying on JDK8. None of them are really to do with the functionality, performance or backwards compatibility of JDK11 vs JDK8. On the consumer side, legacy doesn't really cut much ice as an argument to stick with JDK8. GraalVM is too new a technology for that to be too much of a concern. I think the major reason users want to stick with JDK8 is inertia and (understandable) worry about the unknown. On the product side I think the problem with GraalVM moving on to JDK11 has been that the sheer colume of work involved in getting GraalVM fully working on JDK8 has limited forward progress on JDK11.

There are actually some good reasons to move up to JDK11. Of course, JDK8 /is/ an LTS release, so it is still being provided (by the OpenJDK community) with security fixes and critical functional fixes and will continue like that for several more years. Indeed, you can get commercial support from a variety of vendors until at least 2025. However, note that the JDK8 release used by GraalVM is not a build of the vanilla OpenJDK8 project code. It is actually a derived version modified by Oracle i.e. it is not the same as the OpenJDK8 that, for example, is shipped with most Linux distributions.

The reason for that is that the Graal JIT compiler needs the compiler plugin mechanism developed in JDK9 - a feature called JVMCI (VM Compiler Interface). So, the JDK8 releases shipped with GraalVM are the latest OpenJDK8 release updated with a backport of JVMCI. The Oracle Graal team are doing a very thorough job of maintaining this variant JDK8 to allow you to use the current GraalVM. However, this requires a lot of extra maintenance and constitutes an extra surface for security and functional defects. JVMCI is already present in the JDK11 maintained by the OpenJDK engineers so this extra work and risk is already covered by the OpenJDK project.

Another reason to move up to JDK11 is that AArch64 support is not available in the GraalVM JDK8 release. There /is/ actually a standard AArch64 Linux JDK8 shipped with all AArch64 Linux implementations but the code this is derived from was only incorporated into OpenJDK in JDK9. So, Oracle's variant does not work on AArch64. Once again, maintaining a separate AArch64 JDK8 is extra work (for Red Hat in this case) and provides an extra risk surface. This issue may be remedied soon if the JDK8 AArch64 port is integrated into the main JDK8 code as is currently being discussed. However that would then increase the work Oracle will need to do to maintain their JVMCI backport (at the least it requires more testing) and also the risk involved. Moving GraalVM on to JDK11 would really be a better solution as it would allow more resources to be targeted on improving GraalVM.

[thomaswue]

Yes, agreed @adinn. We are treating JDK 11 support as the #1 priority at the moment.

[Wooyme]

I made it on both Linux and Windows. Here is the demo

[tsatatwer]

More than one year we are the Javafx developers and lovers waiting from GraalVM people the Javafx native solution , and before that we have waited long for Windows support and some just have very good of giving a long speech about not supporting Java 8 although it is the most used.
Although respecting and appreciating all efforts BUT it is very frustrating just to see some giving a speech of what version he thinks and would like to be supported and what not .

[ZhenFTW]

Any News??

[tsatatwer]

We are in the very long waiting...we appreciate any update .

[johanvos]

I'm not sure what kind of update you expect to see here? People are creating native JavaFX 11 images for Mac, iOS and Linux, using the instructions at https://github.com/gluonhq/client-samples.

Once GraalVM for Java 11 is available for Windows, using the JNI platform, it won't be hard to create images for Win as well.

[imReker]

@johanvos Windows GraalVM Early Adopter has been released for a while and GraalVM's JDK 11 support will be released in next month, so, is there any chance to expect a preview version of Gluon Client for Windows recent?

[tsatatwer]

@johanvos update on the issue of creating native Javafx image for windows .
GraalVM Community Edition 19.0.0 released this on May 9 2019 include first build for Windows .
You have written this on Jun 23 :

This is currently working on Mac, Linux and iOS. See https://github.com/gluonhq/client-samples (docs for Linux are not there yet).
We're working on Windows and Android now.

So we appreciate your efforts thanks for updating us on the issue and we are waiting patiently the native Javafx image for windows.

[johanvos]

The release you refer to is Java 8 based. We work with 11 and beyond.

[thomaswue]

And we have announced 11 support for version 19.3 that is scheduled for release in November.

[tsatatwer]

@thomaswue this issue has been opened more than one year with all respect what has been done by you and your colleagues to create Javafx native image???? just praising Java 11 sorry to say that BUT I have to say it .
I praise Java 11 too and Java 8 and all Java versions !!!!!!.

[thomaswue]

@tsatatwer Please keep the conversation polite. @johanvos and others have done large amounts of work to enable native images with JavaFX. Their work is gated on full Java 11 support for GraalVM, which we will release in November. You can learn more about JavaFX native images for example at the JFX days in Zurich on 2nd of December: https://www.jfx-days.com/

[tsatatwer]

It is polite , and this conversation is the most active javafx native image and maybe the oldest and longest one , sorry I and maybe others are frustrating AND agree that @johanvos and others have done large amounts of work to enable native images with JavaFX.

[ZhenFTW]

So does that mean i only need to wait for graalvm for java 11 and wait for your update? Wow now i can dream of using native JAVAFX on windows

[ZhenFTW]

I cant really wait to use try this on windowss pleaseee

[iw-an]

Hi is there an update for the scheduled November release?

[dougxc]

https://www.graalvm.org/docs/release-notes/version-roadmap/ provides dates for upcoming releases.

[didibus]

If I understand, this issue is still considered Open because Windows is missing? Or are there any other limitations as well which keep it from being considered resolved?

[thomaswue]

JDK 11 is the important part - which will come with next week's release.

[ZhenFTW]

Next Week? I thought its tomorrow. The roadmap shows its tomorrow right ?

[tsatatwer]

Release Date : Nov 19, 2019: 19.3

[ZhenFTW]

Its been tomorrow still waiting

[tsatatwer]

@johanvos GraalVM Community Edition 19.3.0 has been released with jdk 11 .
I hope our very long waited for Windows support will come to its end , we appreciated your efforts and others to bring Javafx native image on Windows , and sorry for any frustrating comments from me .

[mryvz]

I ve succeeded building and running openjfx native image on Mac using graalvm 19.3. Thank you all !

[thomaswue]

Be aware that this could be a fallback image. Current information on GraalVM 19.3 + JavaFX is posted by @johanvos at: https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/

We will add a guide regarding JavaFX plus native image to our documentation in the near future.

[Skhmt]

I still can't do it on Windows.

[tsatatwer]

We are still waiting for Windows ??????

[johanvos]

The samples at https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX already show how you can create native executables for JavaFX applications on Linux, MacOS and iOS.

Those samples use a maven plugin, which is also open-source at https://github.com/gluonhq/client-maven-plugin . If you look at the recent commits, you see we're adding Android there.

This maven plugin will invoke calls on Gluon Substrate, which is also open-source: https://github.com/gluonhq/substrate.
You can see Windows is work-in-progress, and we are very transparent about the progress, e.g. see https://github.com/gluonhq/substrate/blob/master/src/main/java/com/gluonhq/substrate/target/WindowsTargetConfiguration.java

Hence, we're getting there.
The great thing is: you don't need to wait. All of this is open source. If you feel it's not going fast or good enough, you can contribute and make it happen. See https://github.com/gluonhq/substrate, bottom of that page for instructions on how to contribute.

[tsatatwer]

The great thing is: you don't need to wait. All of this is open source. If you feel it's not going fast or good enough, you can contribute and make it happen. See https://github.com/gluonhq/substrate, bottom of that page for instructions on how to contribute.

Well it is really great wait or contribute why not??? I have to think about this offer .Thanks

[tsatatwer]

@johanvos , could you please kindly give us an update on windows support progress .Thanks

[SDIDSA]

A lot of times has passed, I'm very grateful for the efforts being made and wishing to know about the current state and release dates

[tsatatwer]

Several months passed and we are just waiting for Windows Javafx native image to be supported and no word at all .....all efforts went to other operating systems BUT very little made on Windows Javafx native image support....and when we posted a question about the delay we faced critics (check my posts and see) .

[asadganiev]

Guys, how to contribute in solving this issue?

[didibus]

@asadganiev

Hence, we're getting there.
The great thing is: you don't need to wait. All of this is open source. If you feel it's not going fast or good enough, you can contribute and make it happen. See https://github.com/gluonhq/substrate, bottom of that page for instructions on how to contribute.

[phamvanthanh]

Hi have the same problems

Built successfully with x86_x64 Cross Tool Command Promt for VS 2019

Any solutions, guys?

Graphics Device initialization failed for :  d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)
        at com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244)
        at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
        at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.lang.Thread.run(Thread.java:834)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:527)
        at com.oracle.svm.core.windows.WindowsJavaThreads.osThreadStartRoutine(WindowsJavaThreads.java:138)
Caused by: java.lang.RuntimeException: Error initializing QuantumRenderer: no suitable pipeline found
        at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.init(QuantumRenderer.java:94)
        at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:124)
        ... 3 more
Exception in thread "main" java.lang.RuntimeException: No toolkit found
        at com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:272)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:267)
        at com.sun.javafx.application.PlatformImpl.startup(PlatformImpl.java:158)
        at com.sun.javafx.application.LauncherImpl.startToolkit(LauncherImpl.java:658)
        at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:678)
        at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:195)
        at java.lang.Thread.run(Thread.java:834)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:527)
        at com.oracle.svm.core.windows.WindowsJavaThreads.osThreadStartRoutine(WindowsJavaThreads.java:138)

[tsatatwer]

@phamvanthanh

Hence, we're getting there.
The great thing is: you don't need to wait. All of this is open source. If you feel it's not going fast or good enough, you can contribute and make it happen. See https://github.com/gluonhq/substrate, bottom of that page for instructions on how to contribute.

OR wait loooooong .... sorry we are in the waiting since two years .

[phamvanthanh]

Is this one symtom of missing native libs?
@tsatatwer
indeed

[tsatatwer]

@phamvanthanh you mean symptom ......check this maybe it helps hopefully at least for now :
https://github.com/Wooyme/jfx-native-image-demo

[phamvanthanh]

@tsatatwer
Thanks
Build exe without any erros but could not work.

[shelajev]

I think there was progress recently with JavaFX native image on Windows. @johanvos can maybe provide more info, but "We are very pleased to announce that Gluon Substrate can now generate static executables for Windows, based on the latest Java and JavaFX code." (source)

[jbreathe]

@shelajev
Wow, very good news!
Thank you for sharing this news with us!

[shashaanktulsyan]

It works and here is the screenshot to show it. Compiled this morning ^
The black console window is something I don't know how to get rid of. Probably just a matter of a few more builds and releases we will have all features we wanted.

[Wooyme]

It works and here is the screenshot to show it. Compiled this morning ^
The black console window is something I don't know how to get rid of. Probably just a matter of a few more builds and releases we will have all features we wanted.

by making a vb script file and launching the native image from it, you can avoid showing the console window. :D

[Wooyme]

@tsatatwer
Thanks
Build exe without any erros but could not work.

Have you tried to add these options when running?
-Dprism.order=sw -Dprism.nativepisces=false -Dprism.allowhidpi=false -Dprism.text=t2k

[aminabs]

@tsatatwer
Thanks
Build exe without any erros but could not work.

Same issue for me if I generate the exe on windows 8.
But if I build the exe on windows 10 I am able to run it on windows 8.

Note: If you put a label inside a StackPane as the root of the scene it is compiled to exe and run without any problem. But if you put a button inside a HBox and put the hbox inside the StackPane as the root, it is compiled but not run.

I've opened the isssue here
https://github.com/gluonhq/client-samples/issues/88

[texasbruce]

Is Gluon the official solution?

Also the binary is huge - a simple window (like HelloFX in their example) results in a binary of 56M. Might as well just modulize and use custom JRE

[XeonG]

https://github.com/gluonhq/gluon-samples/issues/72

is this the same issue.. default project HelloFXML project runs fine with no fxml changes, add in any other component that wasn't already in the default setup and it just doesn't work on windows.