Are there any sample about using compose desktop with R8?

# compose-desktop

[Tlaster]

Are there any sample about using compose desktop with R8?

[romainguy]

R8 converts directly to dex byte code I believe so that wouldn't work for desktop

[Tlaster]

compose desktop release package file is 100MB+, so I wonder if is there any way to reduce the package file size

[romainguy]

I'd be surprised if the binary size is mostly from .class files. It's much smaller on Android. I bet a lot of it comes from native libraries. There might also be other stuff included that shouldn't be there. Have you peeked inside the jars?

[Tlaster]

I check the installed folder (on mac is xxx.app open as a folder, not the uber jar) and most of the sizes come from the compose framework, a simple skiko can take up to 30MB.

[romainguy]

Skiko can't be removed by R8, it's absolutely necessary but I'm sure jetbrains could make it smaller

[romainguy]

I also imagine a JRE is included?

[Tlaster]

Yes, a complete JRE is included

[romainguy]

Yeah so R8 is really not where you are going to get real savings

[eygraber]

I vaguely remember a discussion here about using proguard for compose desktop

[hfhbd]

R8 supports converting to java class code, but you still need skiko and the included JRE, so I don't think reducing size is significant.

[Tlaster]

So we can only use proguard to reduce the size? 100MB+ for a simple desktop app is quite large for me.

[Michael Paus]

I’d like to warn a little bit because hunting for ever smaller distribution sizes easily becomes a kind of fetish. The sizes may sound large for mere hello world programs but serious application are often much larger than this and nobody cares.

[mcpiroman]

I'm using Proguard but it does not make much savings in the size.
It's the packed JRE that takes 68MB in my case. And it should be somehow possible to reduce that - e.g. JB Toolbox had manage to go down to 43MB. So I'd explore that direction first.
But still, there is more work to do in the CfD itself - e.g. there is a duplicated 1MB jar file as reported here

[Michael Paus]

Did you explicitly specify a list of the JRE modules in your desktop build.gradle.kts which you really need for your app?

See: https://github.com/JetBrains/compose-jb/blob/master/tutorials/Native_distributions_and_local_execution/README.md#configuring-included-jdk-modules

Something like:

compose.desktop {
    application {
        mainClass = "MainKt"
        nativeDistributions {
            targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
            packageName = "jvm"
            packageVersion = "1.0.0"
            modules("java.base","java.naming","java.prefs","java.scripting","java.sql","jdk.jfr","jdk.unsupported","jdk.unsupported.desktop","<http://jdk.crypto.ec|jdk.crypto.ec>","jdk.localedata")
        }
    }
}

[mcpiroman]

Yes, I have. But those do not make much difference either.

[alexey.tsvetkov]

Soon (in 1-2 weeks I hope), we will release the simplified Proguard integration for Compose Desktop Gradle plugin.
After that we might look into R8 as well (the configuration should be almost 1-to-1 as proguard), AFAIK it should work with class files, and even supports reading JDK 9+ module files (jmod).
My testing with our standard examples (widgets gallery & code viewer) showed noticeable reduction in distribution sizes. For Widgets Gallery:
• Uncompressed app directory: 129.7 Mb -> 96 Mb (-25%);
• Compressed dmg installer (Mac): 76Mb -> 40 Mb (-47%).
Code viewer example showed similar reductions.
Of course reductions are going to depend on an amount of actually used dependencies, but it seems worth it for small & medium sized apps.

[romainguy]

Beyond size reduction, R8 provides nice benefits in terms of code organization and optimization when it comes to Compose. In particular it can merge lambdas into fewer classes which helps with startup times, etc.