PUBLIC OBJECT

Metrics for OkHttp’s Kotlin Upgrade

We’re upgrading OkHttp’s implementation language from Java to Kotlin. It’s a big process, especially as we’re maintaining strict compatibility with OkHttp 3.x. Fortunately we’ve done it before and we’re following the strategy Egor & I presented last year.

Today we reached a nice milestone: 100% of the production code in the OkHttp module is Kotlin!

We haven’t made any behavior changes so it’s a rare opportunity to compare Java vs. Kotlin while holding everything else constant¹.

Code Size

Java: 25,775 lines
Kotlin: 24,114 lines

7% fewer lines of code is underwhelming. But by doing a strict conversion we’re stuck with all of the Java ceremony we’d otherwise do without. For example, our ConnectionSpec class spends 100 lines on accessors, equals(), hashCode(), toString() and its Builder. Without these this class would be 40% fewer lines of code.

Compile Time

Java: 2.4 seconds
Kotlin: 10.2 seconds

These times are for a full compile of the code above. It’s consistent with what Uber recently reported. Kotlin wants incremental builds and small modules!

Binary Size

Java: 415 KiB
Kotlin: 670 KiB

Seeing a 60% larger binary surprised me. Where is that extra code coming from?! Decompiling shows that there’s much more code going to JVM overloads, Kotlin metadata, null checks, and companion objects.

Modern Abstractions

Kotlin spends space and time on stuff I want: safety, immutability, and expressiveness. I’m optimistic about the upgrade and hope to ship OkHttp 4.0 later this summer.

 

¹ If you’d like to check my work, here’s the Java commit before the upgrade and Kotlin commit afterwards.