Support older API versions (pre java 8 - Android APIs 16-19)

[tomjhall]

I am using version 0.10.3 - I raised a ticket arrow-kt/arrow#1798 around running Arrow with Android APIs 16-19

I would like to see support for Android API versions 16 and up. According to the distribution chart - APIs 16-19 accounts for ~ 10% of devices - by having some support for older versions it may help with adoption of the Arrow libraries in the Android ecosystem.

A quick look using animal sniffer against 0.10.3 it appears only the arrow-fx library is affected:

• To support API 19 - ForkJoinPool (in IODispatchers.kt) is not supported
• To support API 16 - Throwable#addSuppressed is not supported

[nomisRev]

Hi @tomjhall,

Can I ask you what your use-cases are?

Other libraries such as KotlinX Coroutines are also API 21+

Both issues mentioned above don't have a clear solution.

• To support API 19 - ForkJoinPool (in IODispatchers.kt) is not supported

We could replace ForkJoinPool with a custom work stealing pool but KotlinX Coroutines also uses ForkJoinPool on the JVM. That was the one of the reasons for this decision.

• To support API 16 - Throwable#addSuppressed is not supported

Not sure what a solution would be for this. CompositeException could make it harder to debug, and e.printStackTrace might also a great solution depending on where these calls occur.

[tomjhall]

Hi @nomisRev,

My use case is I am writing a Library that currently needs to have backwards compatibility back to API 16.

I was unable to find where KotlinX Coroutines is compatible for API 21+? Can you point me to that? The lines here: https://github.com/Kotlin/kotlinx.coroutines/blob/a70022d6e7d9aa5d8fe27a2c46e987a2e8b85c21/kotlinx-coroutines-core/jvm/src/CommonPool.kt#L60-L62 indicate that kotlin coroutines checks for java 6 & implements a 'plain pool' instead - although my understanding on this could be wrong.

As for Throwable#addSuppressed - I was thinking perhaps throwing a composite exception in this case (for api 16) would be better than not supporting that api - it may be harder to debug on that platform, but at least it's supported. I think the android support/compat libraries have a degraded compatibility philosophy where they try to emulate where possible but give degraded/no support where it's not possible.