Can this be fixed for the final 1.11.0 build? Coro...

# compose-desktop

[Kirill Grouchnikov]

Can this be fixed for the final 1.11.0 build? Coroutines is now two major releases behind.

[Ivan Matkov]

Long story short: no

1. runtime module was fully upstreamed and 1.11.0 was already published by Google from AndroidX repo.
2. Dependencies here are about ">=" rule, they are not "locked" or "behind". The general rule for libraries is to have minimal compatible version in dependencies. So, it should not be updated to the latest one "just because" in principle.

[Kirill Grouchnikov]

When both 1.9.0 and 1.11.0 of coroutines are in the classpath (from my Gradle task that copies all transitive dependencies to one folder), I get this:

Exception in thread "AWT-EventQueue-0" java.lang.NoSuchMethodError: 'java.lang.Object kotlinx.coroutines.BuildersKt.runBlockingK$default(kotlin.coroutines.CoroutineContext, kotlin.jvm.functions.Function2, int, java.lang.Object)'

[Ivan Matkov]

I don't have much info here, but it's probably not about "both in classpath", it's about broken backward compatibility.
It usually happens when new version of library removes API that was in previous version and it was used in some other library that compiled against old version. In this situation library that compiled against old signature cannot find a method in a version that loaded in classpath (new one).

It it's not an issue with packaging but really backward compatibility bug, please file an issue to coroutines library.
To update dependencies it's better to file an issue to Google tracker here.

We can do nothing from CMP side here

[jw]

Yeah that looks like you're putting both 1.9 and 1.11 on the classpath and then the JVM does first-win semantics per class (so you could actually get a mix of 1.9 and 1.11 classes). You should be copying from the resolved classpath which will apply constraints to resolve each coordinate to a single version.

That function was added in 1.11 so whoever is using it should have a 1.11 dependency. https://github.com/Kotlin/kotlinx.coroutines/commit/e5a7b428506c3c1e31eb5b5fa3fe812e8b797896#diff-339272aa30544e4ab13c2daaf50891927916f46915a92419bb04d8d6ef6cdd23

1.11 is obviously > 1.9, so only 1.11 should show up from your copy.

[Kirill Grouchnikov]

For each project, I'm getting the right thing with

val runtimeClasspath =
    project.configurations.matching { it.name == "desktopRuntimeClasspath" }

That gives me a single version of kotlinx-coroutines-core-jvm

For most of the modules in Aurora, the coroutines dependency is transitive from the core Compose itself. But for one module, since I'm using runBlocking explicitly, I defined an explicit dependency on the latest version of coroutines. So in that module, I am getting only 1.11 in the resolved runtime classpath, while in others I am getting only 1.9 in the resolved runtime classpath. And then I end up dumping all these module dependencies into a single folder.

[Kirill Grouchnikov]

Removing that explicit dependency in https://github.com/kirill-grouchnikov/aurora/commit/517a21003057169aa7b4b17edf5a340e48426bc1 and now getting whatever transitive version of coroutines. Since it's only used for the module that takes documentation screenshots of Aurora skins, it's fine if it's lagging behind a couple of releases.

[jw]

Yeah so you're bypassing the Gradle normal dependency resolution with that last step. You either need to create an uber configuration that depends on all the others and then copy from that, or you need to do a folder per-module.

[Kirill Grouchnikov]

The only place I need those combined jars is for taking screenshots, so technically I don't need to copy the dependencies of every single module - just the dependencies of the screenshot module.

Thanks for the explanations here!