Consider dropping support for Java 6 in kotlinx.coroutines 1.4

[qwwdfsad]

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]

From Android's perspective, the use of ForkJoinPool would set your minimum supported API level at 21 which would mean Throwable.addSuppressed would be natively available and not need desugared. Default interface methods still need desugared below API 24, but as you said users upgrading to 1.4 would likely have the necessary updated tooling in place (and their builds will fail if they don't).

[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.

[JakeWharton]

What specifically are you looking for from 8 that is not available in 7? Also do you mean the APIs of 8, the classfile format version, or both?

[fvasco]

I am considering class version 52.
It supports default method in interfaces, it is the point 4 in the list.

Personally I don't consider supporting Java 7 a worth, nor for Android now for regular JVM software.
Further similar issues can be solved using multi-release JARs, so upgrade to Java 8 as minimal requirement should be enough for a while.

[JakeWharton]

Classfile version 52 and Java 7 APIs is acceptable from an Android perspective. Java versions essentially are meaningless when talking about Android support anyway. API 21 is a reasonable minimum-supported version and the toolchain can handle classfile version 52.

[elizarov]

@JakeWharton What would be the easiest way to automatically (during CI) verify that we are only using APIs that are available in certain Android API version and what minimum API version you'd recommend to support for a core library like kotlinx.coroutines?

[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]

Possibility to piggyback on FJP (...) on Android

The current custom scheduler provides a concrete improvement on non Android platform?
In other words: is it possible to focus development on a mature API using already provided battle-tested utilities like FJP?