Upgrade OkHttp 3 to Kotlin and call it OkHttp 4

Inspired by Okio 2 (blog post, presentation), OkHttp 4 is almost exactly like OkHttp 3, except the implementation language is Kotlin instead of Java. We punt breaking API changes to a hypothetical OkHttp 5 that remains in our icebox.

Goals

Implemented in Kotlin with a dependency on the Kotlin standard library. We want the option to support coroutines and multiplatform including Kotlin/Native .

Compatible with OkHttp 3.x. We want 100% binary compatibility so .jar files compiled against OkHttp 3.x will run against OkHttp 4.x without modification. We’ll need japicmp to enforce this. We also want 100% source compatibility for Java callers. Kotlin callers will not be source-compatible but we’ll offer automated upgrades via the language’s rich deprecation facilities. One surprising consequence of this approach is that the Maven coordinates and package name of OkHttp 4 will be okhttp3.

No performance regressions. We must write careful Kotlin, paying attention to abstractions that have a runtime cost.

Tasks

• Migrate from Maven to Gradle.
• Integrate japicmp.
• Get a japicmp release with this fix and delete all the suppressed methods.
• Migrate public API types
• Adopt Kotlin idioms everywhere appropriate (examples)

FAQ

Why Kotlin? It’s a great language for both applications and libraries. It gives us options to execute on more platforms including iOS. Coroutines are powerful concurrency abstractions that may allow us to implement nonblocking I/O without hating ourselves.

Isn’t Kotlin just a trend? It’s backed by the best tools maker and the default language of the most popular mobile platform. It has a simple upgrade path from Java.

Java already has var and I heard Java 13 will have string literals. The Java language is moving faster than ever and adding many great features! But Java has deep layers of technical baggage (checked exceptions! null! JavaBeans™) and I don’t want it for my children. Also, Oracle wants to copyright APIs and I think that’s gross!

Did you just say iOS?! It should be possible to use OkHttp’s requests, responses, and interceptors with a NSURLSession backend. If that works it’d be a pretty awesome way to write networking code for mobile apps.

When will Retrofit/Moshi/Okio/Wire be migrated to Kotlin? Okio is already there. We’re doing OkHttp and Wire right now. No firm plans for Retrofit and Moshi.

Can I stay on OkHttp 3.x forever? We’re hoping that you won’t have to. It’s our job to make OkHttp 4 compelling enough that the cost of this upgrade is justified.

[bsideup]

Too bad that one of the best http libraries for the JVM is no longer a good choice. Sad to see that the world does not learn from previous mistakes (Java libraries in Groovy / Scala).

One of the best things about OkHttp/Okio was the fact that it was zero-dependency library and it was easy to shade it. This is no longer true 🤷‍♂️

I will leave this comment here, please come back and tick “+1” next time you fix “OkHttp doesn’t work with Kotlin version X.Y.Z”-like issues 😅

[VISTALL]

I agree with @bsideup.

There no way for exclude kotlin libraries, and that will be painful when more than one kotlin runtime exists in classloader with different versions.

As java developer, I don’t saw any positive news. iOS ? Nope. Kotlin? (I’m not mobile developer) Also - nope.

Can I stay on OkHttp 3.x forever? We’re hoping that you won’t have to. It’s our job to make OkHttp 4 compelling enough that the cost of this upgrade is justified.

It’s my way 🚶 . Later i think need find other http library.

Thanks for okhttp3 👍