Okio 2.x incompatibilities

What version of gRPC-Java are you using?

1.36.0

What is your environment?

Linux and macOS, built with Bazel from sources using the tools provided in this repo, rather than through a Maven dependency. The same repo contains an Android app using OkHttp3 (4.9.1), which depends on Okio 2.8+.

What did you expect to see?

gRPC-Java should build just fine.

What did you see instead?

gRPC-Java either overrides the dependencies and force Okio 1.x (which causes issues with OkHttp3, e.g. https://github.com/square/okhttp/issues/5378), or fails to compile when using Okio 2.8+. For example: https://github.com/grpc/grpc-java/blob/b2e475712d67a0660e1d16d6465a4ccb9b8a6b40/okhttp/src/main/java/io/grpc/okhttp/OkHttpReadableBuffer.java#L43 buffer.readByte() now throws an exception, which causes a compilation error as it’s not caught or thrown by readUnsignedByte(). This points to incompatibilities between Okio 1.x and 2.x, and makes adopting gRPC-Java in any repo using “recent” (mid-2019…) versions of OkHttp an issue. OkHttp3 has been depending on Okio 2.x since its 4.0.0 release.

Steps to reproduce the bug

Depend on both OkHttp3 4.x and gRPC-Java at the same time.

[ejona86]

I’m using gRPC-Java in a Bazel repo

Oh, okay. Then we’ll need to get this fixed up. Since EOFException is a checked exception build will fail if we continue using okio 1.x in our build. We can workaround that by making a trash function that just “throws EOFException” and calling it within the try.

Out of curiosity, is bumping the Okio version pulled by gRPC-Java something that could be considered and/or done?

I’ve considered it on multiple occasions. The additional dependencies would be a bit of a pain as users pick them up, but could be dealt with. But I sort of hate looking through the Kotlin code (I can’t read it) so I’ve not been eager to personally push that upgrade forward.

[Kernald]

No worries, thanks!