binary-compatibility-validator VS kotlinx.coroutines

It’s an add-on, that brings Kotlin/JS API support to the KotlinX Binary Compatibility Validator (BCV) based on the generated TS definitions. Closes feature request Kotlin/binary-compatibility-validator#42

https://github.com/Kotlin/binary-compatibility-validator is used to verify the public API hasn't changed. I don't know if it works with Java.

On the binary compatibility, I've found this post on Kotlin binary compatibility to be very very helpful. Also, for library authors, Kotlin has a binary compatibility validator that can be plugged into the build to ensure no accidental binary incompatibility occurs.

This was caught by my CI since I verify binary compatibility using binary-compatibility-validator gradle plugin.

A common tool you can use for Kotlin projects is the Binary compatibility validator plugin. This plugin calls annotations that mark API that shouldn't be considered public "non-public markers".

The Kotlin team had added a bunch of tools to help SDK developers including this binary compatibility validator. This helps ensure you aren't adding errant new methods

I have another article about how JetBrains observes these binary incompatible changes by using binary compatibility validator and how library developers can use it in their own projects (it was written before standalone plugin release).

Now, let's consider an example. For instance, let's create a Kotlin/JVM project with kotlinx.coroutines library as a dependency.

Greetings community, I just submited a PR to Kotlin coroutines with two additional operators :

The harder parts of Kotlin are going to be things like kotlinx.coroutines, but that's just a library, not a core part of the language. It's about as hard to learn as a comparable library in another language, like the Task Parallel Library in .NET.

Kotlin has coroutines that are supported by the language and implemented by a library (the implementation remains platform-dependent): kotlinx.coroutines and a sandbox environment is available here to try it out.

That said, since it seems like you're doing UI stuff (Android?), you're best off doing all of the UI code in coroutines, using Dispatchers.Main as a context (as provided by one of the platform-specific coroutine libraries), since this will guarantee that your UI code will be safely run in the UI thread.