Consider dropping support for Java 6 in kotlinx.coroutines 1.4

Supporting Java 6 target creates a lot of maintenance burden and it would be nice if we could migrate to Java 7 or 8. A lot of widespread Android libraries work only with Java 8, Android toolchain knows how to desugar Java 6+ API (except for java.time that we don’t use) and it’s unlikely that there are users sitting on old Android toolchain, Java 6, but on the latest kotlinx.coroutines.

This issue is created to gather feedback and/or objections about such migration.

List of potential features blocked by Java 6 support:

1. ClassValue in stacktrace recovery (instead of a concurrent map of weak references that is prone to class leaks)
2. Possibility to piggyback on FJP for both Dispatchers.Default and Dispatchers.IO (using ManagedBlocker) on Android. It will reduce the size of resulting dex with kx.coroutines by ~20 KB and will share threads with common pool (less memory consumption -> better footprint on low-end devices)
3. JvmDefault to evolve our public interfaces in a backward-compatible way (also, less bytecode)
4. Proper addSuppressed without reflection or jdk8 jar.
5. Better stacktrace recovery (inspect constructor parameters names reflectively) …

[JakeWharton]

For OkHttp and Okio (which are also Kotlin multiplatform projects) we use Animal Sniffer on the JVM targets to ensure compatibility. For example, OkHttp supports Java 8 on the JVM and API 21 for Android so we configure both of those: https://github.com/square/okhttp/blob/master/build.gradle#L112-L119.

I personally think API 21 is a reasonable minimum supported version. The global platform dashboard (which inexplicably hasn’t been updated since May) at https://developer.android.com/about/dashboards paints roughly 10% below that line, the most of which is 7% on API 19 (API 20 doesn’t really exist). You can speculate that those numbers are even lower by now since they only go down. It’s a long tail to zero though so I would not consider a non-zero number worth supporting simply because it exists.

Choosing a higher minimum supported version will always bring complaints. Plenty of people will be supporting API 19 and potentially even lower. You’ll want your choice to be defensible. In OkHttp’s case API 21 meant modern cipher suites are guaranteed which ensured the privacy of its user’s data. I think the desire to use FJP unconditionally is a pretty strong position given the code size and runtime performance/memory impact.

It will also have interesting implications on the AndroidX libraries which depend on coroutines. Most (all?) of them support API 14+ for no real good reason other than historical and no strong motivation to move. I would not let that play a factor in your decision. They’ve been forced to bump the minimum of various modules before and those modules can decide to stick to a 1.3 dependency to retain compatibility or bump for new features just like everyone else.

(All of this is my personal view as an Android developer. If you need some official Android position that’ll be a whole other ordeal)

[fvasco]

it would be nice if we could migrate to Java 7 or 8

Please consider Java 8 only, I don’t see any worth in Java 7 support.