<https://medium.com/graalvm/graalvm-21-0-introduci...

# compose-desktop

[suresh]

https://medium.com/graalvm/graalvm-21-0-introducing-a-new-way-to-run-java-df894256de28#ddc7:~:text=build%20native%20[…]g%20applications%20on%20Linux - New graalvm release added native image support for AWT and Swing applications on Linux. Hopefully this will allow us to create native image of compose applications 🙂

[spierce7]

My thought was that graal wasn’t supported because of Swings usage of reflection. I don’t really know what I’m talking about though.

I assumed that because compose doesn’t use reflection, that Graal was an option. Am I wrong?

[gildor]

Swings usage of reflection

It’s also true, but graal can use reflection, if you define what kind reflection for which classes you are using

[gildor]

So it’s about swing/awt support in graal itself

[spierce7]

I see - I didn’t realize that.

[gildor]

I think the biggest problem in terms of support swing/awt is native rendering itself

[spierce7]

there are paid tools that allow swing apps with graal I thought

[gildor]

with graal native image?

[spierce7]

yeah - I found it while investigating this like 6 months ago

[Michael Paus]

What exactly do you expect from a natively compiled Compose app? A substantial application (anything more than a hello-world example) will neither be smaller nor faster than a carefully packaged one (via jlink and jpackage). With class data sharing (CDS) you can also reduce the startup time, which has actually never been a real problem for me because for larger apps this is often dominated by other factors anyway. (I have some experience with all that from my JavaFX background. The only real justification for it is getting a JavaFX app onto iOS because Apple doesn’t allow JITs there. (Getting a modern Java and JavaFX onto Android is an aspect which is not relevant here.))

[suresh]

(via jlink and jpackage). With class data sharing (CDS) you can also reduce the startup time, which has actually never been a real problem for me

Yeah that’s correct. I think major thing will be the memory footprint. A static image uses significantly less memory than JIT. At least that’s what i have seen with micronaut static images vs running on jvm.

[Michael Paus]

According to my JavaFX experience exactly that is not true. It is not unusual that the executable created by native-image is twice as large as the packaged application. It is getting worse the larger the application is. Here is something that I have written up about this: https://github.com/mipastgt/JFXToolsAndDemos/blob/master/docs/articles/JFX-Bundles/JFX-Bundles.adoc The binary format of a native image seems to be far less efficient (memory-wise) than the very compact java class file format.

[spierce7]

So another potential interest is decompilability. I don’t know for certain, but I suspect that You couldn’t just grab the jars and decompile them like you can with jlink.

[Michael Paus]

Yes, I doubt that you can reasonably decompile a native image especially as the decompiled code would not be complete. It contains just the part that you needed in your specific use case.

[gildor]

I wouldn't rely too much that not specially obfuscated code will be very safe in terms of decompilation
Contrary, there are many JVM tools which do obfuscation