Feedback wanted: Migration to stable coroutines in Kotlin 1.3


As announced in Kotlin 1.3-M1 blog post coroutines are graduating and are becoming a stable feature in Kotlin 1.3. Migration to the graduated coroutines would require removing experimental from all the package names as well as adjustments to the usages of certain low-level APIs like Continuation and advanced functions from intrinsics package.

We are releasing an updated version of all JetBrains libraries like kotlinx.coroutines for graduated coroutines. However, if you happen to be using 3rd party library that exposes experimental coroutines in its APIs and the maintainers of that library would not perform a timely update to the Kotlin 1.3 graduated coroutines, then you’ll find that you cannot use the functions in those libraries that expose experimental coroutines if your project is configured with Kotlin language level 1.3 — Kotlin compiler will report an error on an attempt to use them.

Hereby we are gathering feedback to decide on what kind of support we would need to provide for that scenario in Kotlin 1.3 release. Please, respond if you are using any 3rd party non-JetBrains libraries that you do not control and which expose experimental Kotlin coroutines in their APIs. We are interested to know what libraries are those and how exactly the experimental coroutines are exposed by those libraries:

  1. They expose suspend functions.
  2. They receive or return suspend functional types.
  3. They receive, return or otherwise expose types from kotlinx.coroutines.experimental package and thus would prevent you from fully migrating to the version of kotlinx.coroutines library for Kotlin 1.3 which removes experimental from all the package names.

Links to your applications and the corresponding libraries’ code (if possible, of course) would be extremely helpful.

Please, feel free to comment if you feel that you would be otherwise inconvenienced by inability to use code that was compiled with Kotlin language level 1.2 and exposes experimental coroutines from the code that is being compiled with Kotlin language level 1.3.

CoroutineScope.coroutineContext deprecated, how do I do it now?


For android the most popular are:


We use vertx-lang-kotlin-coroutines:
It exposes suspend functions and functions returning Channel


On Android I’m using Fuel’s coroutines:


Well, I have a super-tiny library which probably noone uses except me :yum:, but don’t worry … as soon as the new Kotlin is out, I will flip it to 1.3 :wink:. Which keeps me thinking that due to backward incompatibility I will have to jump from version 0.0.1 straight to the 0.1.0 :grin:. Anyway if you need any analysis, it is here:


kotlin-coroutines-retrofit now available also for Kotlin 1.3 in version 0.12.0-eap13


Here are some coroutines libraries I use:


This an Android library that transforms callback based Bluetooth Low Energy scanning to a ReceiveChannel.

  • A public constructor takes a CoroutineContext which defaults to CommonPool.
  • A public method returns a ReceiveChannel.
  • All the code is in an experimental sub-package.

Note that I am the maintainer of this library.


This is an Android library that transforms callback hell based Bluetooth Low Energy connection and communication to suspending functions.

  • A ConflatedBroadcastChannel is exposed (although it’s likely to get deprecated in the next version).
  • A ReceiveChannel is exposed.
  • Many public suspend functions are exposed.
  • All the code is in an experimental sub-package.

Note that I am the maintainer of this library.


This is an Android library that transforms callback hell based Camera2 API to a kind of suspending DSL.

It is currently work in progress. The sample can already record videos properly, but there’s still work to do to support all of the Camera2 API, including API 28 additions (upcoming Android P with multi-camera support).

I’m also the maintainer of this library, but I only use it in the sample at the moment, I copy pasted it as a library module in the project where I needed it, and I’ll replace it manually when the library is ready.

It is not released on jcenter at the moment.

I just noticed I forgot to add all the code into an experimental sub-package. Now that coroutines graduation is coming, and that you ask for feedback for migration, without giving much information about how it’ll happen really, I feel seriously lost about how I should manage it. And soon to be deprecated Android support libraries vs not API stable yet AndroidX/Jetpack migration makes me a bit more lost on what is the right way to publish a library that uses both. I also wonder if there’s any link between “Jetifier” and the tooling you may provide for Kotlin coroutines and kotlinx.coroutines migration.

Splitties preferences:

This is an Android library bringing property syntax for Android shared preferences.

The preferences module has an optional dependency to org.jetbrains.kotlinx:kotlinx-coroutines-android (compileOnly).

It provides an abstract class named SuspendPrefsAccessor (which is in an experimental sub-package) that is made to be extended by the companion object of the Preferences subclasses. Its constructor takes a CoroutineDispatcher parameter and the class provides a suspend operator fun invoke().

Here’s a usage example in the sample.

Note that I am the maintainer of this library, as you probably guessed from my pseudo matching the repo owner.


  • Exposes public suspend extension functions.


This library does not really expose any suspend related functions, only the implementation deals with the Deferred type. Migration for this library is very simple, you just have to change the artifact name and version, dropping the experimental word in the dependency identifier, and voilà, the package didn’t change, and no suspend or coroutines related types were part of the public API.

The fact that this library didn’t follow the recommendations for experimental coroutines and experimental kotlinx.coroutines usage, yet has a migration that is currently easier than for kotlinx.coroutines itself leaves me wondering about what I should do as the maintainer of 4 libraries that rely on these graduating experimental features, plus several projects using these libraries. *I feel the need for some guidance to do it right.

IIRC, it has both kinds.


I am writin a lib: and just started to use coroutines internal (not in exposed api). Since this is new I am not using experimental packages. I wonder how this affects lib users? They will not be able to use it if they are using experimental coroutines?