Hi, is it possible (i.e. has someone tried) to com...

# compose-desktop

[uli]

Hi, is it possible (i.e. has someone tried) to compile a compose desktop application with GraalVM to native executable?

[Lukas K-G]

I haven’t tried it but it was briefly mentioned in the talking Kotlin episode about Compose for Desktop

[Stefan Oltmann]

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.

[uli]

Thanks for your thoughts. I also did some more research and found out that AWT is only yet supported by GraalVM on Linux

[Michael Paus]

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.

[Stefan Oltmann]

Gluon is really ugly. Tried that already.

[Michael Paus]

What do you mean by “ugly”.

[Stefan Oltmann]

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.

[Stefan Oltmann]

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.

[Stefan Oltmann]

@Michael Paus Are you affiliated Gluon? It's the first time I hear someone say that Gluon works nicely. 😅

[Stefan Oltmann]

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.

[Michael Paus]

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.

[Stefan Oltmann]

Ok, some time has passend since the evaluation.
Nice to see that they actually have a gradle plugin now and work on the docs. 👍

[Stefan Oltmann]

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.

[Michael Paus]

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?

[Stefan Oltmann]

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.

[smallshen]

https://github.com/oracle/graal/issues/3807