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

Glavo commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

tisonkun commented 6 years ago

For cross refer #358

psini commented 6 years ago

Any news?

alexandrenavarro commented 6 years ago

Any news?

ssmooncoder commented 6 years ago

Any news?

chengenzhao commented 6 years ago

Any news?

tsatatwer commented 5 years ago

Any news please.

chengenzhao commented 5 years ago

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 commented 5 years ago

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

Glavo commented 5 years ago

@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 commented 5 years ago

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

ssmooncoder commented 5 years ago

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

cubuspl42 commented 5 years ago

@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 commented 5 years ago

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

tsatatwer commented 5 years ago

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

chengenzhao commented 5 years ago

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

tsatatwer commented 5 years ago

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

4ntoine commented 5 years ago

any update? 1.1 year passed

johanvos commented 5 years ago

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 commented 5 years ago

Thanks for update! Sounds great

вс, 23 Июн 2019, 22:25 Johan Vos notifications@github.com:

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 .

nithyasharabheshwara commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

tsatatwer commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

+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 commented 5 years ago

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

Wooyme commented 5 years ago

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

tsatatwer commented 5 years ago

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 commented 5 years ago

Any News??

tsatatwer commented 5 years ago

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

johanvos commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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

thomaswue commented 5 years ago

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

tsatatwer commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

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.

oracle / graal

[native-image] Native image of JavaFX application can not run #403