I've just stumbled into a binary incompatibility issue. ``` java.lang.NoSuchMethodError: No dire...

# announcements

[Daniele Segato]

I've just stumbled into a binary incompatibility issue.

java.lang.NoSuchMethodError: No direct method <init>(Lkotlin/coroutines/CoroutineContext;I)V in class Lkotlinx/coroutines/flow/internal/ChannelFlow; or its super classes (declaration of 'kotlinx.coroutines.flow.internal.ChannelFlow' appears in /data/app/~~ccBt4dlqHFv3AkedliSnSw==/redacted.package.name.debug-QqdNYvkOKVfFKcKUHZwhVg==/base.apk!classes18.dex)
        at kotlinx.coroutines.reactive.PublisherAsFlow.<init>(ReactiveFlow.kt:51)
        at kotlinx.coroutines.reactive.PublisherAsFlow.<init>(ReactiveFlow.kt:50)
        at kotlinx.coroutines.reactive.ReactiveFlowKt.asFlow(ReactiveFlow.kt:30)

I had a library compiled with

org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.9

My project used a more recent version

org.jetbrains.kotlinx:kotlinx-coroutines-core:1.4.2

this apparently caused a binary incompatibility....

It is troubling to me because asFlow wasn't marked experimental.

should I open a ticket / tweet to someone about it?

I shouldn't need to release a new version of the library to make it binary compatible with greater versions.


WHY this is DEEPLY troubling:

If the language doesn't guarantee binary backward compatibility with a previous minor version (1.3.x -> 1.4.x) it means that developers will have to constantly update libraries and eventually maintain multiple versions compiled against multiple version of kotlin for projects that still use a previous minor.

THIS IS A NO GO for any language.

Libraries compiled for Java 6 run just fine on Java 13.

I'm not kotlin need to be that conservative, but at least not break backward compatibility on stable api between minors? Deprecate them for a couple of minors is ok. This is not.

[Marc Knaup]

Afaik minor version updates (like 1.3 -> 1.4) aren’t supposed to be binary compatible 🤔

[Daniele Segato]

If that's the case than we'll soon end up with many different version of libraries

compiled against kotlin 1.3.x
compiled against kotlin 1.4.x
compiled against kotlin 1.5.x

this can become a mess really quick
backward compatibility for a language is important

[Marc Knaup]

That’s already the case with Kotlin updates - to a certain degree. No idea about coroutines.

[Daniele Segato]

Well that's an HUGE problem. Makes me reconsidering using kotlin.

[Marc Knaup]

I didn’t have too many issues with that in the past three years. Minor updates don’t happen that often.

[Marc Knaup]

https://kotlinlang.org/docs/reference/evolution/kotlin-evolution.html#evolving-the-binary-format

[Marc Knaup]

Also check https://kotlinlang.org/docs/reference/evolution/components-stability.html

[Marc Knaup]

And https://kotlinlang.org/foundation/language-committee-guidelines.html

[Daniele Segato]

@Marc Knaup those 3 links say exactly what I've been saying.

For an api marked as STABLE is not acceptable that binary compatibility is broken just by going up 1 minor.

[Marc Knaup]

Normally, incompatible changes to stable features only land in feature releases.

https://kotlinlang.org/releases.html

We ship different types of releases:

• Feature releases (1.x) that bring major changes in the language.

[Daniele Segato]

I've created a bug on this
https://youtrack.jetbrains.com/issue/KT-43903

[Marc Knaup]

https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.4.0-M1

• Changed ABI in reactive integrations for Java interoperability (#2182).

[Marc Knaup]

Not sure if that covers your exception though

[Marc Knaup]

It also doesn’t seem to be considered breaking

[Marc Knaup]

You’re using the wrong issue tracker:
https://github.com/Kotlin/kotlinx.coroutines/issues

[Daniele Segato]

Ah, I'm not at the PC anymore. Will post it there as soon as i can.

[Arkadii Ivanov]

I hit another incompatibility with this update: https://twitter.com/arkann1985/status/1331892399686217734?s=19

[Daniele Segato]

Compose is alpha tho'. Breaking changes are to be expected

[Arkadii Ivanov]

But the thing is, Compose was broken due to binary incompatibility in coroutines!

[Arkadii Ivanov]

So any library could be in place of Compose

[Daniele Segato]

Oh yeah, that is concerning

[gildor]

It's not language btw, it's kotlinx.coroutines, which is library

All links above are about language and stdlib.

But anyway, kotlinx.coroutines uses semantic versioning, so it shouldn't cause any binary incompatible changes for stable APIs

I would just create an issue on kotlinx.coroutines tracker

[gildor]

As I see, it's a problem with Channel Flow, which is experimental, maybe It's somehow leaked to non-experimental API

So an issue is way to go, it shouldn't be a case when non-major release cause binary incompatibility

[Daniele Segato]

@gildor you are right, coroutines is a library, but it is part of the kotlin SDK and as such i consider it part of the language to the same extent I consider the java.time api part of the language.

Sure, It's added as optional dependency, so it's not exactly the same thing, but that's only because there's no JVM for kotlin so you only add what you need to an app.

[gildor]

java.time is very different, it not only doesn't require any additional dependency, but also system specific and cannot be easily unbundled (because of timezones mostly) so it's not a good example

[gildor]

Because kotlinx.coroutines is not a part of language, none of compatibility rules about language compatibility are not relevant for it

[gildor]

But this is incorrect, because kotlinx.coroutines use sem ver, they should keep binary compatibility for minor releases
https://kotlinlang.slack.com/archives/C0922A726/p1607707137472200?thread_ts=1607706898.472000&cid=C0922A726

[Marc Knaup]

Ah, yes, I’ve missed this document:
https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/compatibility.md#stable-api

Too many documents on that topic 😅