Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Okio 2 #370
This is our design document for Okio 2.
Okio 2 should be 100% API-compatible with Okio 1.x for Java uses of our library. This includes using the same Maven coordinates, the same package name, and an upwards-compatible API. We should use build tools to confirm this compatibility.
Okio 2 should have equivalent performance to Okio 1. We may need to write careful Kotlin, paying attention to abstractions that have a runtime cost.
We do not strive to be 100% API-compatible for
We will not support coroutines from the 2.0. As above, we merely want the option of adding these later.
We need to migrate from Maven to Gradle. Though Maven has served us quite well, Gradle is better supported for multiplatform projects. Part of this migration includes migrating our use of some Maven plugins like Animal Sniffer.
We need to figure out how to check binary compatibility with our existing APIs. We should keep our
We should ship a multiplatform proof-of-concept. Perhaps this is supporting some subset of
We need to decide for each Kotlin-convenience method whether to duplicate (two ways to do the same thing), or find a way to offer the nicer Kotin form only. This might be difficult, particularly for methods like
Why Kotlin? Because it’s really good. It’s a wonderful language to build Java libraries and applications with. It has abstractions that make it possible to write code that is both compact and efficient.
Tell me more about Kotlin. We’d like to write code that runs on both iOS and Android, and Kotlin/Native is quite promising. Kotlin coroutines allow us to get the scalability of java.nio without ugliness.
But isn’t Kotlin just a trend? Not if we have anything to do with it. By doing Okio 2 in Kotlin we’re making a big commitment to the language, and we hope others will follow us here.
When will OkHttp/Retrofit/Moshi/Wire be migrated to Kotlin? No firm plans at the moment. But if we have success with coroutines in Okio, those libraries will want to take advantage. And it’d be really neat to get OkHttp working on iOS.
Can I stay on Okio 1.x forever? We’re hoping that you won’t have to. It’s our job to make Okio 2 compelling enough that the cost of this upgrade is justified. But we don’t indend to require Okio 2 in OkHttp and Retrofit until their next major revision.
Great timing, great decision. Is there any precedent for this in major open source libraries that can point to how seamless the transition is, I assume following https://android.github.io/kotlin-guides/interop.html?
Also is the iOS OkHttp target valuable given swift-nio and on Android side cronet?
Given Kotlin's official Android support for the last year+ - “Skate to where the puck is going, not where it has been.”
I don’t know about any similar efforts in other projects. I think we’ll borrow from how the Kotlin standard library interacts with JVM types.
I don't think iOS developers necessarily want another HTTP client! But I want to share networking code between platforms. This should help with that.
referenced this issue
Apr 30, 2018
Don't think this will lead to a lot of confusion, if only for the exception they throw (