okio icon indicating copy to clipboard operation
okio copied to clipboard

okhttp3 depends on okio-3.6.0 and okio-jvm-3.6.0 which causes problems in Java-maven projects

Open rolfschumacher opened this issue 4 months ago • 4 comments

Here is a part of my mvn dependency:tree. I removed okio-3.6.0.jar form module path and my application worked.

[INFO] +- com.openai:openai-java:jar:3.0.2:compile [INFO] | +- com.openai:openai-java-client-okhttp:jar:3.0.2:compile [INFO] | | +- com.openai:openai-java-core:jar:3.0.2:compile [INFO] | | | +- com.google.errorprone:error_prone_annotations:jar:2.33.0:compile [INFO] | | | +- io.swagger.core.v3:swagger-annotations:jar:2.2.31:compile [INFO] | | | +- com.fasterxml.jackson.datatype:jackson-datatype-jdk8:jar:2.18.2:runtime [INFO] | | | +- com.fasterxml.jackson.datatype:jackson-datatype-jsr310:jar:2.18.2:runtime [INFO] | | | +- com.fasterxml.jackson.module:jackson-module-kotlin:jar:2.18.2:runtime [INFO] | | | | - org.jetbrains.kotlin:kotlin-reflect:jar:1.8.10:runtime [INFO] | | | +- com.github.victools:jsonschema-generator:jar:4.38.0:runtime [INFO] | | | | - com.fasterxml:classmate:jar:1.7.0:runtime [INFO] | | | +- com.github.victools:jsonschema-module-jackson:jar:4.38.0:runtime [INFO] | | | - com.github.victools:jsonschema-module-swagger-2:jar:4.38.0:runtime [INFO] | | +- com.squareup.okhttp3:okhttp:jar:4.12.0:runtime [INFO] | | | - com.squareup.okio:okio:jar:3.6.0:runtime [INFO] | | | - com.squareup.okio:okio-jvm:jar:3.6.0:runtime [INFO] | | | - org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.9.10:runtime [INFO] | | - com.squareup.okhttp3:logging-interceptor:jar:4.12.0:runtime [INFO] | - org.jetbrains.kotlin:kotlin-stdlib-jdk8:jar:1.8.0:compile [INFO] | - org.jetbrains.kotlin:kotlin-stdlib-jdk7:jar:1.8.0:compile

rolfschumacher avatar Aug 19 '25 12:08 rolfschumacher

Graph looks fine. The okio jar is empty and okio-jvm has all the code.

JakeWharton avatar Aug 19 '25 13:08 JakeWharton

Hi, Jake

thank you for response.

both 3.6.0 export the same packages, hence you can not have both on the Java module path. If you automatically create the module path from the dependencies, Java reports the error

==== Error occurred during initialization of boot layer java.lang.module.FindException: Two versions of module okio found in target/lib (okio-3.6.0.jar and okio-jvm-3.6.0.jar)

That means, okhttp should not be dependent on okio-3.6.0, just okio-jvm-3.6.0.

BR Rolf

On Tue, 19 Aug 2025 06:26:26 -0700 Jake Wharton @.***> wrote:

JakeWharton left a comment (square/okio#1682)

Graph looks fine. The okio jar is empty and okio-jvm has all the code.

rolfschumacher avatar Aug 19 '25 13:08 rolfschumacher

Neither is a proper module so they don't export any packages explicitly.

❯ unzip -p ~/Downloads/okio-3.9.1.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0


❯ unzip -p ~/Downloads/okio-jvm-3.9.1.jar META-INF/MANIFEST.MF
Manifest-Version: 1.0
Automatic-Module-Name: okio

I guess if you're relying on the implicit module name then it will collide with the explicit name of okio-jvm.

For now I would recommend using dependency substitution rules to resolve okio to okio-jvm so that only the latter ever appears in the dependency graph and the resuling classpath (or modulepath, in this case).

We can look at specifying an explicit alternate name for the okio.jar.

JakeWharton avatar Aug 19 '25 14:08 JakeWharton

To give one of them a different module name would surly help. Thank you. It's just that one does not really know what they are doing if they manually delete a dependency - here okio-3.6.0.jar - that mvn depencency:tree shows to be necessary.

Am I right your main target development environment is Kotlin? Taken JPMS into account, too, would be a benefit.

rolfschumacher avatar Aug 20 '25 07:08 rolfschumacher