https://kotlinlang.org logo
Title
u

uli

09/16/2021, 8:52 PM
Hi, is it possible (i.e. has someone tried) to compile a compose desktop application with GraalVM to native executable?
l

Lukas K-G

09/17/2021, 6:17 AM
I haven’t tried it but it was briefly mentioned in the talking Kotlin episode about Compose for Desktop
s

Stefan Oltmann

09/17/2021, 6:57 AM
I used to have a much simpler application (without compose-jb) build with GraalVM and already hat a lot of very strange problems. At this stage I really can't recommend "GraalVM native image". It's just not ready.
u

uli

09/17/2021, 7:00 AM
Thanks for your thoughts. I also did some more research and found out that AWT is only yet supported by GraalVM on Linux
m

Michael Paus

09/17/2021, 9:39 AM
In the JavaFX world GraalVM native image is used heavily if you build native images for desktop (Mac,Win,Linux) and mobile (Android, iOS) with the Gluon tool chain and in general that works nicely if you do it right. What makes things a bit tricky is the “closed world” assumption of GraalVM native image but with the native image agent this can be handled too. I’d also be interested to get Compose going with that because in contrast to the current solutions (KMM) this would in principle make it possible to get Compose applications working on all these platforms based on a common JVM backend. My problem with KMM at the moment is that I would have to write a separate GUI with SwiftUI for iOS and I don’t have a Kotlin replacement for all the Java libraries that I am using in my code. With a GraalVM/native image approach this would not be a problem anymore.
s

Stefan Oltmann

09/17/2021, 9:40 AM
Gluon is really ugly. Tried that already.
m

Michael Paus

09/17/2021, 9:42 AM
What do you mean by “ugly”.
s

Stefan Oltmann

09/17/2021, 9:44 AM
It's badly documented for a start. And of course closed source. Looking for a RoboVM replacement we tried a really small prototype with "Gluon Mobile", but this was very complicated to do. They do not even support Gradle. After trying that out nobody wanted to go with Gluon.
Yes, you need separate iOS and Swift if you choose KMM. But I think it's the best thing to do anyway because you have maximum control now.
@Michael Paus Are you affiliated Gluon? It's the first time I hear someone say that Gluon works nicely. 😅
The idea of Gluon enable JavaFX devs to go cross platform is really good. I had my own cross platform framework before using native Android, JavaFX and RoboVM for iOS. Gluon hat RoboVM as iOS backend before and switched to GraalVM. So I don't know how good it works before that. 🤷‍♂️ It's nice that Gluon repaired the Scene Builder and I would recommend that version, but Gluon Mobile is really not a good product - sadly.
m

Michael Paus

09/17/2021, 10:03 AM
The documentation is not that bad. See yourself: https://docs.gluonhq.com/ Here is the link to the Gradle plugin: https://github.com/gluonhq/gluonfx-gradle-plugin The core technology is not closed source. It’s all on GitHub. There are only some higher level products which build on these technologies which are Gluon products. And no, I am not in any way affiliated with Gluon. I know there are problems but they are not so much related to the base technology which would be relevant for Compose.
s

Stefan Oltmann

09/17/2021, 10:05 AM
Ok, some time has passend since the evaluation. Nice to see that they actually have a gradle plugin now and work on the docs. 👍
It's not Open Source to a level that when they close down the project you can take over. A strong point for RoboVM was that it could be forked by the community and as you know exactly that had to be done. If Gluon shuts down that will be a big problem. People should also take that into consideration. If I remember right there was also a problem with integration of native iOS frameworks. RoboVM had the Bra Java to Native bridge which worked good, but as time of evaluation we found no option with Gluon Mobile. Beside strange compiling errors, bad docs (at least at that time) and it's limits we choosed to avoid Gluon.
m

Michael Paus

09/17/2021, 10:27 AM
Sorry if I disagree. All the core technology is Open Source. It has either been donated to the OpenJFX project or to GraalVM itself, which themselves are open projects. The core tooling https://github.com/gluonhq/substrate is under GPL and even the plugins have a BSD license. So what else do you need?
👍 1
s

Stefan Oltmann

09/17/2021, 10:31 AM
Ok, looks like you are right. 👍 In that case I wasn't aware that substrate actually contains that much. So this point of mine is invalid. Sorry for that.
s