Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade OkHttp 3 to Kotlin and call it OkHttp 4 #4723

Closed
4 of 5 tasks
swankjesse opened this issue Mar 14, 2019 · 44 comments
Closed
4 of 5 tasks

Upgrade OkHttp 3 to Kotlin and call it OkHttp 4 #4723

swankjesse opened this issue Mar 14, 2019 · 44 comments
Milestone

Comments

@swankjesse
Copy link
Task lists! Give feedback
Member

@swankjesse swankjesse commented Mar 14, 2019

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.

@swankjesse swankjesse changed the title Upgrade OkHttp 3 to Kotlin and Call it OkHttp 4 Upgrade OkHttp 3 to Kotlin and call it OkHttp 4 Mar 14, 2019
@swankjesse swankjesse added this to the 4.0 milestone Mar 15, 2019
@yschimke

This comment has been hidden.

@swankjesse

This comment has been hidden.

@alosdev

This comment has been hidden.

@JakeWharton

This comment has been hidden.

@JakeWharton

This comment has been hidden.

@yschimke

This comment has been hidden.

@swankjesse

This comment has been hidden.

@bsideup
Copy link

@bsideup bsideup commented Mar 19, 2019

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
Copy link

@VISTALL VISTALL commented Mar 19, 2019

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 👍

@rafal-glowinski
Copy link

@rafal-glowinski rafal-glowinski commented Mar 19, 2019

@VISTALL there are plenty of companies that use Kotlin for their backend services.

@VISTALL
Copy link

@VISTALL VISTALL commented Mar 19, 2019

@rafal-glowinski but not all (and not even 50% of them). It's a holy war ⚔️

@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Mar 19, 2019

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!

@bsideup
Copy link

@bsideup bsideup commented Mar 19, 2019

@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.
Most probably, we will stay with okhttp3 as long as it works, but also start looking for another library in parallel.
Why? Because we're not ready to depend on an language ecosystem just because one of our dependencies have decided to cut some boilerplate. I wish Kotlin adds "stdlib-less" mode.

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.

@bsideup
Copy link

@bsideup bsideup commented Mar 19, 2019

I wonder what @fabric8io folks think about it, I guess it will also affect their Java-only libraries

@VISTALL
Copy link

@VISTALL VISTALL commented Mar 19, 2019

@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)

https://developer.android.com/kotlin/faq

What's Kotlin's impact on APK size / method count?

The Kotlin runtime adds about 7,000 methods and ~1MB to your debug APK. The net impact might be less if you use Kotlin to replace another library in your project, such as Guava or RxJava. This size also reduces when you optimize the APK for release with Proguard, just like other app code and libraries.

(android not provide kotlin runtime)

You forced for use Kotlin runtime, or use old versions.

@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Mar 19, 2019

For Okio 2 the shaded + pruned cost of the stdlib is 7 KiB.

@yschimke

This comment has been hidden.

@swankjesse

This comment has been hidden.

@yschimke

This comment has been hidden.

@LouisCAD
Copy link

@LouisCAD LouisCAD commented Mar 19, 2019

@VISTALL You should always use Proguard/R8 for release apks. When doing so, you can even end up with an apk lighter than with Java thanks in part to inlining.

@galderz

This comment has been hidden.

@swankjesse

This comment has been hidden.

@bnorm

This comment has been hidden.

@swankjesse

This comment has been hidden.

@yschimke

This comment has been hidden.

@swankjesse

This comment has been hidden.

@swankjesse

This comment has been hidden.

@shenliuyang

This comment has been hidden.

@swankjesse

This comment has been hidden.

@swankjesse

This comment has been hidden.

@yschimke

This comment has been hidden.

@swankjesse

This comment has been hidden.

@swankjesse

This comment has been hidden.

@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Jun 1, 2019

I’ve got a branch with the latest japicmp report. Only interesting binary-compatibility change is a bunch of accessors that became final in OkHttpClient. Otherwise going from 3.14 to 4.0 is no problem for Java callers.

@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Jun 1, 2019

Here’s what I want to do before the release:

  • Write a migration section for the changelog. This should include a list of incompatible changes and deprecations. Use KotlinSourceCompatibilityTest to find these!
  • Change all -deprecated_ to DeprecationLevel.ERROR. This might mean we have to delete KotlinSourceCompatibilityTest!
  • Cut the 4.0.0-RC1 release for early adopters.
  • Do a performance comparison with 3.14.x. Try to find regressions!
  • Hide Kotlin-internal APIs from Java. Use annotations like @file:JvmName("-Base64").
  • Write a blog post announcing the release.
@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Jun 11, 2019

Quick and dirty benchmarks reveal no performance regressions.

@BoxResin
Copy link

@BoxResin BoxResin commented Jun 20, 2019

Would Android 5.0+ requirement be eliminated in v4?

@swankjesse
Copy link
Member Author

@swankjesse swankjesse commented Jun 20, 2019

OkHttp 4 has the same requirements as OkHttp 3.13+

@swankjesse swankjesse closed this Jun 27, 2019
@gitahinganga
Copy link

@gitahinganga gitahinganga commented Jul 15, 2019

Upgraded to OkHttp 4 last week. Now I can't release my Android app without multidex because I have exceeded the 64K limit. OkHttp 4's Kotlin dependencies add approximately 7K method references. I don't want multiple dex files, certainly not because of one library, so I am downgrading to OkHttp 3. Or does anyone have any suggestions about how to address this issue better?

@avently
Copy link

@avently avently commented Jul 15, 2019

Maybe proguard can help

@ZakTaccardi
Copy link

@ZakTaccardi ZakTaccardi commented Oct 23, 2019

We are developing server software and microservices

Kotlin fully supports your use case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet