Announcing Okio 2: Our fast + simple I/O library, Okio, has a new release that supports Kotlin.
Heads up, we’ve moved! If you’d like to continue keeping up with the latest technical content from Square please visit us at our new home https://developer.squareup.com/blog
At Square, we’re excited about Kotlin. It’s a capable language to build Java libraries and applications with. We love to write code that is both compact and efficient.
Today we’re releasing Okio 2.0. In this release we’ve converted the project’s source code from
.kt. The conversion lets us use Kotlin in the library and offer APIs that feel right when the calling code is in Kotlin. It also gives us the opportunity to support multiplatform and coroutines in the future.
The new release is binary-compatible with Okio 1.15.0. You can replace the old
.jar file with the new one and your applications and libraries should just work.
The update is also Java source-compatible. When you configure your
build.gradle to use the new version you won’t have to change any
.java code to get a clean build. (Our changelog notes one minor exception to this, unrelated to the Kotlin transition.)
But the update is not Kotlin source-compatible; it adopts Kotlin idioms where they apply. For example, if you’re using
ByteString.decodeHex("f00d") you’ll now need
"f00d".decodeHex(). We’re using Kotlin’s
@Deprecated annotation for a smooth upgrade process.
Okio is core to many of Square’s open source projects. We use it for fast I/O in OkHttp, Retrofit, Moshi, and Wire. When these projects upgrade to Okio 2 they will gain a transitive dependency on Kotlin’s standard library.
Kotlin is the best language for Android application development. We expect many Android teams to already be using Kotlin. For their projects Kotlin is already among the applications’ dependencies. Those that don’t can use R8 or ProGuard to shrink the Kotlin library dependency. When we measured, the net increase was negligible: just 7 KiB.
For server applications we expect the dependency size to be inconsequential. But we worry about potential diamond-dependency versioning problems. To minimize the chance of such problems we will avoid experimental and deprecated APIs.
For libraries and SDKs that use Okio or its sibling libraries we assume the ultimate deployment target will be to Android or a server. In either case we believe the dependency is acceptable.
Kotlin is a beautiful language with broad applications. We hope Okio 2 helps to further extend Kotlin’s capabilities.
Get the new Okio with Gradle: