Proguard will remove SwingDispatcherFactory (MainDispatcherFactory) on JVM about kotlinx.coroutines HOT 10 OPEN

Filed an issue for the Compose documentation: JetBrains/compose-multiplatform#4288

@amal, I saw the issue, but the maintainers didn't even respond to it yet. In any case, the scheme for supplying rules on Desktop, even if they do support that, may end up different from what they use for Android, so it's meaningless to adapt our code right now to hypothetical future changes that we don't know anything about.

from kotlinx.coroutines.

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

from kotlinx.coroutines.

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.

from kotlinx.coroutines.

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.

from kotlinx.coroutines.

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

from kotlinx.coroutines.

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).

from kotlinx.coroutines.

./gradlew app-desktop:runReleaseDistributable

I get

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

Is this expected?

from kotlinx.coroutines.

@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..

from kotlinx.coroutines.

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 ?

from kotlinx.coroutines.

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.

from kotlinx.coroutines.