Open dkim19375 opened 3 years ago
Have you found a solution? I also found this problem but couldn't solve it
Have you found a solution? I also found this problem but couldn't solve it
Nope :/
I think that you'd have to either:
Does Jetbrains Compose could make native image right now?
Does Jetbrains Compose could make native image right now?
I don't know, but it doesn't use CSS, which is why I put it on the reply. (and the error seems to be about using the CSS url protocol)
Would love to see TornadoFX or JetBrains Compose who first supports GraalVM native image.
Would love to see TornadoFX or JetBrains Compose who first supports GraalVM native image.
What happens when you use Compose?
Would love to see TornadoFX or JetBrains Compose who first supports GraalVM native image.
What happens when you use Compose?
Tbh I haven't tried to migrate Compose to native image yet, but neither did I find any documents or blog posts about how to do it
Would love to see TornadoFX or JetBrains Compose who first supports GraalVM native image.
What happens when you use Compose?
Tbh I haven't tried to migrate Compose to native image yet, but neither did I find any documents or blog posts about how to do it
Native image doesn't need specific docs for each library (unless there's compatibility issues like TornadoFX), as it just "converts" the JAR
to an EXE
@dkim19375 I just tried on Compose using a HelloWorld example with Graalvm 17 CE, Native Image can only produce a fallback image, which still requires a JDK to run
@dkim19375 I just tried on Compose using a HelloWorld example with Graalvm 17 CE, Native Image can only produce a fallback image, which still requires a JDK to run
O
wait have I been misunderstanding native image all this time-
@dkim19375 The reason why generating a (non-fallback) native image is hard is because the native image doesn't allow any Java reflection. https://www.graalvm.org/22.0/reference-manual/native-image/Limitations/
This requires a closed-world assumption, where all code is known at image build time, i.e., no new code is loaded at run time. As with most optimizations, not all applications are amenable for that optimization. If an application is not optimizable, then a so-called fallback image is generated that launches the Java HotSpot VM, i.e., requires a JDK for execution.
@dkim19375 The reason why generating a (non-fallback) native image is hard is because the native image doesn't allow any Java reflection. https://www.graalvm.org/22.0/reference-manual/native-image/Limitations/
oh hmmmm then I'm assuming Compose wouldn't work either
oh is that what you meant by
Native Image can only produce a fallback image, which still requires a JDK to run
?
@dkim19375 Pretty much, that's why I am waiting to see Compose and TurnadoFX who will support the (non-fallback) native image first.
Btw, pure JavaFX (by Gluon JavaFX) is already supported to be built as a GraalVM native image, but that is with pure Java code and without DI. It might be possible to integrate Kotlin into it, but I haven't tried it yet nor will I try it as I would prefer TornadoFX or Compose
When using native image with TornadoFX, I get this warning:
and when running the
exe
, it throws an exception -Anyone know how I'd fix this? My overall goal is to avoid installations, including java and this program itself (which GraalVM Native Image does), so if anyone can find an alternative or know a solution, please let me know! :)