Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Upgrade OkHttp 3 to Kotlin and call it OkHttp 4 #4723
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.
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
No performance regressions. We must write careful Kotlin, paying attention to abstractions that have a runtime cost.
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.
"We want the option to support coroutines" - I hope you will consider making this a fundamental feature of the design for 4.0. It feels like a big part of the win for users moving from 3 to 4. While the win without is for the sanity of OkHttp developers.
... without breaking compatibility :)
Yeah, staying compatible is the trick. If everything were on the table we’d make our interceptors suspending. But that’s too disruptive for Java.
I’d be happy to add a Call extension that suspends:
What’s the right name for this?
Too bad that one of the best http libraries for the JVM is no longer a good choice.
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
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.
It's my way
Thanks for okhttp3
We are going to be very conservative with which Kotlin standard library features we use. It's extremely important to me and to this project that we make it easy to stay up-to-date and also secure.
Please give us a chance to be your preferred HTTP library for the JVM. Despite the fact that OkHttp uses Kotlin, we are still very concerned with usability from Java. Square maintains a huge number of Java services that use OkHttp and we need to keep those working smoothly!
@swankjesse let me explain our use of the library:
We ( http://github.com/testcontainers/testcontainers-java/ project ) have migrated from Netty to OkHttp because we wanted to have a zero dependency http library (and shade-able).
We care about the amount of dependencies because the library is popular, being used in many different projects, with different dependencies on its own, and every new dependency we add may lead to a conflict (as seen many times in the past). Even the most stable / popular ones caused us some headache.
This is not just a panic.
Thanks for a great library, we enjoyed it so far, I respect your decision because obviously the project is very Android-focused, but wanted to provide some details why we regret about this decision and how it affects another, slightly less yet popular Java library.
@swankjesse Also. For example android projects. Kotlin is prefer for Android dev, but - nobody restrict java usage. That why - many projects wrote in java, due more easy support it(or just don't want add kotlin).
and here an example:
Java android project, use okhttp, and after update - kotlin runtime required (which will be affect apk file size)
(android not provide kotlin runtime)
You forced for use Kotlin runtime, or use old versions.
There are four kinds we’re going to do that don't warrant much tracking:
For each the most important thing is whether we can do it without breaking any compatibility, including Java source, Kotlin source, and binary compatibility.
I'm reluctant to expose higher-level Kotlin APIs like DSLs. And I'm similarly not ready to adopt coroutines.
With that all said, if you have API ideas please list em!
Second is more of a thought for potential coroutine work. It's a pretty big break to Kotlin source compatibility but something like this in the
referenced this issue
Apr 5, 2019
On the Java Tests (#4914)
To me the requirements in the original description and especially this imply an RC-1 that we can test for source, binary compatiblity and performance regressions. Just want to confirm this is the plan?
The Okio changelog includes a table of changes to adopt Kotlin idioms. For Okio we made these 4 types of changes:
Our migration helpers will have binary names like
These are the public APIs that need Kotlin idioms.