okio as a dependency changed artifactId in 4.10.x release

[honnix]

Since 4.10.0 release, okio, as a dependency, has been changed to okio-jvm from okio. https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp/4.10.0 vs https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp/4.9.3

This is problematic because build tools like maven and gradle will treat them as two different artifacts and pull both of them as dependencies.

As an example:

  <dependencies>
    <dependency>
      <groupId>com.squareup.okio</groupId>
      <artifactId>okio</artifactId>
      <version>2.9.0</version>
    </dependency>
    <dependency>
      <groupId>com.squareup.okhttp3</groupId>
      <artifactId>okhttp</artifactId>
      <version>4.10.0</version>
    </dependency>
  </dependencies>

Will result in both okio-2.9.0.jar and okio-jvm-3.0.0.jar being pulled in as dependencies, while otherwise build tools will only pick up one of those (version resolution is a different story and things like maven-enforcer-plugin will not help in this case). The problem gets harder to be discovered if okio is introduced as a transitive dependency by another artifact.

We also noticed this was reverted in 5.x, see https://mvnrepository.com/artifact/com.squareup.okhttp3/okhttp/5.0.0-alpha.9. So maybe this was introduced accidentally?

[klaraward]

Also related https://github.com/square/okio/issues/1067#issuecomment-1041591598 and https://github.com/square/okio/issues/1121

[klaraward]

This is the PR that bumped okio from 2.9 to 3 - https://github.com/square/okhttp/pull/7225

[yschimke]

Fixed in https://github.com/square/okhttp/pull/7354

[honnix]

@yschimke Thanks for looking into this.

Could you please help me understand how #7354 fixes this issue? As I understood #7354 creates a dependency from okhttp to okhttp-jvm so current Maven users depending on okhttp will not need to change their dependency when upgrading to later okhttp version.

However, since okhttp-jvm depends on okio-jvm, Maven users having both okio and okhttp as dependencies will still end up with pulling in both okio and okio-jvm into classpath, is the right?

Also I see the PR was made towards the main branch so 4.x will not get it.

Let me try to understand the path moving forwards. Is it true starting from okhttp 5.x, using okhttp-jvm together with okio-jvm is the correct way for JVM platform? If that is the case I think #7354 might not help create the awareness.

Was it intended to introduce the similar change to 4.10.x (depending on okio-jvm)? I can understand having this type of change in a major release, but for a minor release it seems too aggressive. Is it possible to revert upgrading okio in 4.10.x?

Thanks again for looking into this issue.

[honnix]

OK I see https://square.github.io/okio/changelog/#version-320 (https://github.com/square/okio/pull/1125) has a similar change. So maybe you could release 4.10.1 to depend on okio-3.2.0 instead of okio-jvm-3.0.0?

[yschimke]

Yep, sorry, you are right, will require a bump and release.

[honnix]

Thank you so much! Looking forwards to a new release. Also thanks for working on the workaround to help users migrate.

[swankjesse]

Yep! I wanna release 4.11.0 that depends on Okio 3.2.0.

[tianshuang]

Yep! I wanna release 4.11.0 that depends on Okio 3.2.0.

@swankjesse When will 4.11.0 be released to fix this?

Our project has both okio:1.12.0 and okio-jvm:3.0.0. When util.kt loads the okio.Options class in okio:1.12.0, it will trigger java.lang.NoSuchFieldError: Companion.