I’m preparing OkHttp 5.0.0 and I’m looking for som...

# squarelibraries

[jessewilson]

I’m preparing OkHttp 5.0.0 and I’m looking for some community help.

Can you please try out 5.0.0-alpha.17 in your projects and let me know if you run into any surprises?

OkHttp 5.x introduces separate -jvm and -android artifacts. We’ve had reports (issue 8826) that some builds incorrectly classes from both a okhttp-android 5.x artifact and a okhttp 4.x artifact, which causes crashes at runtime. I haven’t been able to reproduce this. If you can repro this, please reply on thread; I’d love to get to the bottom of this.

My intention is for 5.x to have zero backwards-incompatible changes with 4.12. If you see any, again please let me know.

[eygraber]

Specifically alpha.17? I've been using the alphas on Android pretty much since they came out, and haven't had any issues (currently on alpha.16).

[jessewilson]

Awesome. Yeah if alpha.16 works for you then 5.0.0 will work too

[Tolriq]

In prod with alpha.16 on Android too and no problem (Min sdk 28)

[mbonnin]

We have a weird case where bumping the version breaks the compileCommonMainKotlinMetadata task because we use Kotlin 2.1 and looks like alpha.17 is compiled with Kotlin 2.2?

[mbonnin]

Looks like another case of KMP not supporting `languageVersion` . Probably nothing to do there, besides warning KMP consumers that they'll need kotlinc 2.2

[mbonnin]

response.body is not nullable any more 🥳 I love this. This got me so confused initially. Could still be a breaking change I believe? At least source breaking and some people might rely on this behaviour?

[mbonnin]

And another KMP thing, I had to align the okio version between JVM and commonMain source sets (here) (JVM would use 3.14.0 from okhttp, commonMain was still on 3.9.0).
Without this NSData.toByteString() doesn't resolve in Apple source sets 🤷

[jessewilson]

I think you could have had code that asserts it’s null, but I don’t think it’s likely to impact real users in practice. It only applies to the Response object returned from networkResponse or priorResponse

[trevjones]

Not sure if it is release note worthy but you can't use v5 in your gradle plugins because of the kotlin version embedded in gradle.

Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 2.2.0, expected version is 2.0.0.

Obviously works fine in the gradle 9 RC but could be a point of friction when upgrading before 9 lands.

[trevjones]

no code changes required for our actual android code though. all tests still passing.

[jessewilson]

That’s a good catch

[mbonnin]

@trevjones as long as okhttp is an implementation dependency and doesn't call any new kotlin-stdlib API, it should work though?
The build scripts usually don't need okhttp in the compile classpath.

[trevjones]

In my case I am pulling it in as a dependency directly. Have a handful of plugins that upload outputs for stuff like i18n, security scanners, and webhooks.

I expect you are correct if it was only transitively included instead of me directly consuming it.

For me its really a non issue, I'll probably just hold off on updating until G9 lands or just list the stuff I need twice so my plugin builds still use 4.12

[mbonnin]

I think part of the issue comes from using embedded-kotlin or kotlin-dsl. That limits the libs you can consume compared to org.jetbrains.kotlin.jvm

[mbonnin]

But that's in a lot of setups so probably worth a heads up

[trevjones]

oh yeah good call there. I just default to using kotlin-dsl because it just feels better

[jessewilson]

https://square.github.io/okhttp/changelogs/changelog/#version-500