grpc-java icon indicating copy to clipboard operation
grpc-java copied to clipboard

Support okhttp3 in the public interface of grpc-okhttp

Open beatrausch opened this issue 4 years ago • 5 comments

Is your feature request related to a problem?

grpc-okhttp does not support okhttp3 compatible versions in its public interface e.g. OkHttpChannelBuilder.

Describe the solution you'd like

Add support for okhttp3 to the public api e.g. OkHttpChannelBuilder to make it easier to use with okhttp3 compatible versions

Describe alternatives you've considered

Stick to the old version of okhttp 2

Additional context

Support both okhttp and okhttp3 in the public interface.

beatrausch avatar Dec 01 '21 19:12 beatrausch

Hi,

after adding the current version of okhttp3, I get the following error during the upper bound check

Execution failed for task ':grpc-okhttp:checkUpperBoundDeps'.
> Could not resolve all dependencies for configuration ':grpc-okhttp:runtimeClasspath'.
   > Could not resolve com.squareup.okhttp3:okhttp:4.9.3.
     Required by:
         project :grpc-okhttp
      > No matching variant of com.squareup.okhttp3:okhttp:4.9.3 was found. The consumer was configured to find a runtime of a library compatible with Java 7, packaged as a jar, and its dependencies declared externally but:
          - Variant 'apiElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares an API of a component compatible with Java 8 and the consumer needed a runtime of a component compatible with Java 7
          - Variant 'javadocElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them packaged as a jar)
          - Variant 'runtimeElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a library, packaged as a jar, and its dependencies declared externally:
              - Incompatible because this component declares a component compatible with Java 8 and the consumer needed a component compatible with Java 7
          - Variant 'sourcesElements' capability com.squareup.okhttp3:okhttp:4.9.3 declares a runtime of a component, and its dependencies declared externally:
              - Incompatible because this component declares documentation and the consumer needed a library
              - Other compatible attributes:
                  - Doesn't say anything about its target Java version (required compatibility with Java 7)
                  - Doesn't say anything about its elements (required them packaged as a jar)

okhttp3 requires java 8. Any ideas on how to get it into the build?

beatrausch avatar Dec 01 '21 19:12 beatrausch

Note for others: this is related to #8610 and its fix #8650.

Hmm... that's troublesome. We can make it a compileOnly dependency, and maybe that will help, but I doubt it will. Since this is Gradle noticing, I suspect it may be difficult to workaround.

We can delay doing this a little bit, as Java 7 support should drop this quarter-ish (#4671). Really, I'd much rather figure out a way to tell Gradle "it's okay; ignore," but I have very little experience with Gradle Modules so I doubt I'll be too much help. I have seen this before, but in that case we stayed on the older version...

ejona86 avatar Dec 02 '21 01:12 ejona86

Let's see, may be I could figure out way to work around that issue.

beatrausch avatar Dec 06 '21 19:12 beatrausch

Hi,

I was not able to work around that issue. Since the current version of grpc-java dropped Java 1.7, I would go for the solution which makes okhttp2 and okhttp3 compileOnly. To do that, I’d like to drop the okhttp2 dependency in the internal implementation e.g., in the OkHttpClientTransport (it is also related to #6119). According to #8004, the portion of okio used in grpc-java works with okio1 and okio2, thus I won’t expect an issue. What do you think?

beatrausch avatar Feb 24 '22 19:02 beatrausch

Removing the dependency on OkHttp from OkHttpClientTransport and then making okhttp2 a compileOnly dependency sounds great. I had intended to do that, but haven't had time. And adding okhttp3 API as compileOnly should be easier now without Java 7. I'll just recommend doing those things as two separate PRs.

ejona86 avatar Feb 24 '22 19:02 ejona86