Has anyone tried building for Compose/Desktop usin...

# compose-desktop

[Mike Dawson]

Has anyone tried building for Compose/Desktop using JDK21 and Proguard? It seems like the Compose plugin uses proguard 7.2, but proguard 7.4 is required for JDK21 support. As per the version docs, JDK17 and above is supposed to be supported.

[Oleksandr Karpovich [JB]]

you can try to use a newer proguard version:

compose.desktop {
    application {
        buildTypes.release.proguard {
              version.set("7.4.2") // for example
        }
    }
}

[Mike Dawson]

Will try that - it seems to me like that should be the default...

[Mike Dawson]

https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-compatibility-and-versioning.html?utm_campaign=kmp&utm_medium=docs&utm_source=github#limitations-of-compose-multiplatform-releases

[Mike Dawson]

This says JDK17 "and later" is supported, which would imply that the default version of proguard is set to a version that is compatible with a supported (LTS) JDK version

[Oleksandr Karpovich [JB]]

That makes sense. We'll need to test that nothing breaks with new default proguard version

[Mike Dawson]

Yes... additional testing with Proguard would be good (including obfuscation enabled). I found out of the box KTOR serialization doesn't work (kotlinx serialization is fine, but ktor .body() calls fail). https://youtrack.jetbrains.com/issue/KTOR-6703/Ktor-Client-body-serialization-fails-on-JVM-when-using-Proguard

[Mike Dawson]

Maybe if all the example projects were use proguard fully (e.g. obfuscation enabled) that would help uncover things.

[Michael Paus]

I’ve been using ProGuard 7.4.0 with Java 21 for a while now and did not notice any failures with that combination. (Just upgraded to 7.4.2)

[Mike Dawson]

What version of Compose are you running? I'm getting a verify error when using Proguard 7.4.2 .

I was able to reproduce that verify error by taking the compose desktop template generated out of the box by the multiplatform wizard, and simply setting the proguard version reproduced the error

[Mike Dawson]

@Oleksandr Karpovich [JB] I think using Proguard 7.4.x doesn't work. I was able to reproduce errors using the out-of-the-box Kotlin multiplatform wizard template by just taking the template and setting the proguard version: https://github.com/JetBrains/compose-multiplatform/issues/3818#issuecomment-1921090223

[Mike Dawson]

Just to be sure: I did post a reproduction sample project

[Michael Paus]

I am using

kotlin.version=1.9.22
agp.version=8.2.0
compose.version=1.6.0-dev1397

and built a fairly large application (compared to the various demos floating around) with it, which supports macOS (X86 & ARM), Windows and Linux. I also just upgraded to version 7.4.2 and did not notice any problems (if you don’t count the tens of thousands of notes and warnings that you get from ProGuard).

[Mike Dawson]

I'm using Kotlin 1.9.20 and Compose 1.5.11 (which were the latest production versions until 3 days ago)

[Mike Dawson]

... versions that the project wizard is still using

[Michael Paus]

I haven’t used these old versions for a while.

[Michael Paus]

When did the error that you describe happen and on which platform? I am developing and building on macOS Sonoma for example. (Windows and Linux on GitHub Action runners.)

[Mike Dawson]

Happened hours ago... using Ubuntu 23.10 with OpenJDK 17. Will see if I get the same result with JDK 21

[Mike Dawson]

Same result with JDK21

[Michael Paus]

I can confirm that your example fails for me too on my Mac with the same error.
The reason is that you did not switch off ProGuard optimization.
With this

buildTypes.release.proguard {
            obfuscate.set(false)
            optimize.set(false)
            version.set("7.4.0")
        }

setup your example works perfectly. I have noticed previously that optimization causes nothing but problems on desktop, so I always switch it off.

[Mike Dawson]

Optimize is enabled by default

[Mike Dawson]

Thank you for testing the example

[Mike Dawson]

Optimize is supported and enabled by default. Obfuscation is (as per the docs) supposed to be supported. So I'd say that's a bug

[Michael Paus]

Your error has also been reported here
https://github.com/JetBrains/compose-multiplatform/issues/3947
and
https://github.com/Guardsquare/proguard/issues/349

[Michael Paus]

Actually I reported this error a long time ago and it was supposed to be fixed but it seems to have popped up again.
https://github.com/JetBrains/compose-multiplatform/issues/3387

[James Hamilton]

It looks like one of the VerifyError issues is the known issue relating to the class/enum/unboxing optimization which you can disable with -optimizations !class/enum/unboxing (https://github.com/Guardsquare/proguard/issues/349)

There is different issue when disabling that specific optimization (not all VerifyErrors have the same cause) in one of the androidx.compose classes.

You can also provide more targeted config than completely disabling optimizations, for example excluding classes from optimization that are causing issues:

-keep,includecode,allowobfuscation,allowshrinking class androidx.compose.runtime.SnapshotStateKt** { *; }

Your sample works for me if you add the following to the compose-desktop.pro config:

-optimizations !class/enum/unboxing
-keep,includecode,allowobfuscation,allowshrinking class androidx.compose.runtime.SnapshotStateKt** { *; }

You'll also need to tell the Compose build to use the config in the Gradle file:

compose.desktop {
    application {
        mainClass = "MainKt"

        buildTypes.release.proguard {
            obfuscate.set(false)
            version.set("7.4.2")
            // Add this line
            configurationFiles.from(project.file("compose-desktop.pro"))            
        }

        nativeDistributions {
            targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
            packageName = "com.ustadmobile.pgvt"
            packageVersion = "1.0.0"
        }
    }   
}

[Michael Paus]

@James Hamilton Many thanks for the feedback. Can you also tell us what benefits we might expect from optimization when the code was generated with a modern compiler and is run only on desktop with the latest Java VM. I am still wondering what kind of optimizations any tool could still do which a modern desktop Java cannot or just doesn’t do for whatever reason.

[James Hamilton]

The optimizations are not just about runtime performance optimizations though some of them are and those may not be as applicable these days as they used to. The other reason to do the optimizations is for shrinking. If you can e.g. remove the uses of a class by some optimization then you can remove the class. For example, if you have an unused parameter which has some class type, the class will be kept by the shrinking step but there is an optimization that removes unused parameters where possible. The shrinker is re-executed after each optimization pass because more classes, methods and fields could become removable. It depends on your application though, so it's best to test it out for your use-case to see how much it improves shrinking and/or performance. You can control which optimizations are applied with the -optimizations option: the available optimizations are listed here https://www.guardsquare.com/manual/configuration/optimizations

In the sample in the comment above, in terms of classes removed: the shrinking step on it's own removes a lot of the unused classes:

Removing unused program classes and class elements...
  Original number of program classes:            8964
  Final number of program classes:               4397

Then after 1 optimization pass, some more are removed:

Removing unused program classes and class elements...
  Original number of program classes:            4397
  Final number of program classes:               4226

If you do another pass (-optimizationpasses 2), a few more are removed:

Removing unused program classes and class elements...
  Original number of program classes:            4226
  Final number of program classes:               4192

[Mike Dawson]

Thank you @James Hamilton for that extra info. I think Proguard is doing what it is supposed to do here, and it is essential to get JVM-based desktop app sizes to be more reasonable.

The problem is that those publishing / distributing libraries and frameworks need to support it publishing rules for shrinking / optimization (especially when they say that it is supported as per docs on stable releases).

In the perfect world, automatic consumption of rules from libraries would be great. Just documenting the rules would be a major start. As I said above, I think all example projects should have optimization and obfuscation enabled so that such issues would be more likely to surface before release.

[Michael Paus]

@James Hamilton Many thanks for the clarifying infos. But I think I will wait with optimization until this has stabilized and works without problems out of the box. I also don’t see any reason trying to squeeze out the last byte from my code as long as we are just waisting more than 20 MB like this: Intel binary in ARM library But I’ll keep an eye on it.