I am working with a usecase where my application is using okhttp [version:3.14.9] which is written in java, I am also importing some external dependency which uses okhttp [version:4.10.0] which is written in Kotlin, the external dependency is using a method of okhttp (4.10.0) which is not in okhttp (3.14.9). since my application during runtime calls the method with the (3.14.9) dependency hence unable to find the method and throws java.lang.NoSuchMethodError.

I know this is such a common problem which every other java application faced at some point of time. So I want to know the right approach which is used widely by most java applications.

CodePudding user response：

There is no proper solution for this problem. You can choose only one version.

Way around this is to use OSGi, but it will require major redesign of your application.

CodePudding user response：

This is a classic problem where you have more than 1 version of the dependency available during the runtime. I would suggest you uplift the version of okHttp in your application to match that of the external dependency. This would remove many headaches like "class path resolution" issues.

If you're using a build tool like Maven, there may be another solution where you use define 3.14.9v as the compile time dependency and include 4.10.0v as the runtime dependency so only 4.10.0v is packaged-in and available during the runtime.

CodePudding user response：

I would try to upgrade my code from 3.14 to 4.10 to match the external dependency. Generally it is good to upgrade packages whenever you can, so this should be a good thing (unless there is a strong reason why you can't). The worse case is when an external dependency forces you to downgrade, which is frustrating but sometimes unavoidable.