Proguard will remove SwingDispatcherFactory (MainDispatcherFactory) on JVM

[mikedawson]

Describe the bug

If you use Proguard on JVM (e.g. as part of a Compose/Desktop application as per compose docs), then the MainDispatcherFactory is removed. When the application runs, it crashes because there is no main dispatcher.

The following Proguard rules are required:

-keep class kotlinx.coroutines.internal.MainDispatcherFactory { *; }
-keep class kotlinx.coroutines.swing.SwingDispatcherFactory { *; }

Proguard on Desktop/JVM doesn't have automatic rule consumption like Android, so documenting the requirement e.g. here https://github.com/Kotlin/kotlinx.coroutines#r8-and-proguard is critical.

Provide a Reproducer

This can be reproduced from this branch of our code:
https://github.com/UstadMobile/UstadMobile/tree/dev-desktop-conveyor

Remove the above lines from app-desktop/compose-desktop.pro , and the crash will be observed.

Alternatively:

1. Create a new Compose JVM/Desktop app
2. Enable obfuscation as per compose docs)
3. Run it.

[dkhalanskyjb]

I'm not sure that's our problem. The classes Proguard removes are explicitly listed as services: https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-swing/resources/META-INF/services/kotlinx.coroutines.internal.MainDispatcherFactory We don't do anything funny with our dispatcher factories, it's the standard Java mechanism: https://docs.oracle.com/javase/tutorial/sound/SPI-intro.html

If we decide that it's a bug that kotlinx-coroutines-swing doesn't provide Proguard rules, then every library out there that provides any services at all must also include the corresponding keep rule for Proguard, or it's buggy, which I think is absurd. I'd recommend raising this problem to Proguard. It's certainly not impossible for them to fix this. For example, R8 recognizes service files and doesn't require such keep rules: https://github.com/Kotlin/kotlinx.coroutines/blob/master/ui/kotlinx-coroutines-android/resources/META-INF/com.android.tools/r8-upto-3.0.0/coroutines.pro

[mikedawson]

I agree that the the proguard situation where rules are handled manually isn't great, but that's how it is. Compose/Desktop multiplatform uses Proguard, not R8 . So either the rules for using any given project need documented, or the developer making a Compose/JVM has to go through all jar dependencies looking for services.

KCEF is documenting this: https://github.com/DatL4g/KCEF/?tab=readme-ov-file#proguard

If someone is using library A via library B, question is who should document this? I think the authors of Library A would need to document their library's proguard requirements, and the authors of library B include the requirements of Library A. Yes it could and should be automated, but the current production toolchain does not have that automation.

[dkhalanskyjb]

What I think is a problem on our side is the error message:

        "Module with the Main dispatcher is missing. " +                        
            "Add dependency providing the Main dispatcher, e.g. 'kotlinx-coroutines-android' " + 
            "and ensure it has the same version as 'kotlinx-coroutines-core'"

When Proguard breaks the correctness of the program, this error message is not helpful. Maybe we could expand the error message to something like

        "Module with the Main dispatcher is missing. " +                        
            "Add dependency providing the Main dispatcher, e.g. 'kotlinx-coroutines-android' " + 
            "of the same version as 'kotlinx-coroutines-core' and ensure that modification doesn't remove " +
            "implementations of MainDispatcherFactory"

Or maybe that's too lengthy, so we could add a Main dispatcher troubleshooting section to README.md and do something like

"Module with the Main dispatcher is missing. See https://github.com/Kotlin/kotlinx.coroutines/README.md#Missing_Main_dispatcher

It would be nice if we could recommend a universal Proguard rule like "keep all classes implementing MainDispatcherFactory," and it looks like we can do that; I'd still need to check this.

@mikedawson, I'd like to use your reproducer. What Gradle command should I run? When I remove the -keep rules from app-desktop/compose-desktop.pro and run ./gradlew proguardReleaseJars, the build succeeds.

[mikedawson]

The build will succeed - but if you remove the keep rule and run it (e.g. ./gradlew app-desktop:runReleaseDistributable it will crash)

[mikedawson]

That said - @dkhalanskyjb I would disagree with just changing the error message. Yes, I think until everyone starts reading documentation, changing the error message is definitely a good idea.

However, the proguard task can take some time. The release compilation can take a while (on my project takes about 4 mins on a machine with 64GB of RAM). If everyone has to build/run/repeat to discover this with a 5-10 libraries, that is a considerable amount of lost time.

Using Proguard is a supported procedure with stable / release versions of Compose/Desktop, so if I follow the documentation for a supported use case, I shouldn't be getting errors with a core use case (eg not an edge case scenario).

[dkhalanskyjb]

./gradlew app-desktop:runReleaseDistributable

I get

Exception in thread "main" java.lang.IllegalStateException: No MediaInfo found

Is this expected?

[mikedawson]

@dkhalanskyjb - yes, our desktop app requires mediainfo. If running ubuntu, you can do apt-get install mediainfo . On Windows you can put it app-resources/mediainfo (our installer build does this itself). If the mediainfo is anywhere on your path command, it will find it..

[dkhalanskyjb]

Managed to pinpoint the problem, thanks.

Ok, so do I get it correctly that you don't want us (the kotlinx-coroutines library) to document the Proguard rules, as the users would still need to go and find that documentation, but instead your problem is with Compose? Do you think it's enough for Compose team to update https://github.com/JetBrains/compose-multiplatform/tree/master/tutorials/Native_distributions_and_local_execution#minification--obfuscation ?

[amal]

FYI, ProGuard can add support for JVM in Guardsquare/proguard#337
Also, it can just be reused manually from the Android task. So I'm sure it's handy to package ProGuard rules in jars.
It's a better future-proof solution than manual configuration by the end user.