Replace okhttp with azure core http

dapr / java-sdk

Dapr SDK for Java

Apache License 2.0

261 stars 207 forks source link

Replace okhttp with azure core http #763

Open tanvigour opened 2 years ago

tanvigour commented 2 years ago

Replace this to fix the dependency issue with okhttp3 https://github.com/dapr/java-sdk/issues/687

tanvigour commented 2 years ago

/assign

mukundansundar commented 2 years ago

@tanvigour why are we replacing one dependency with another?

yaron2 commented 2 years ago

Please do not use an Azure specific HTTP library. Instead, pick a known Java standard.

artursouza commented 2 years ago

The Azure dependency is the same as the OKHTTP but in a different namespace to avoid conflict. There is a well known issue of conflicting OKHTTP version with the app when importing the Dapr Java SDK. It is a major pain point to get started. People have to pick one version to resolve conflict and hope they are compatible. This will stop this conflict.

We also had plans to remove OKHTTP completely and use Java's native HTTP client but that requires Java 11 as minimum support. Right now, we need to keep Java 8 support because of Spring Cloud requirements.

/cc @skyao

tanvigour commented 2 years ago

@tanvigour why are we replacing one dependency with another?

To fix the version compatibility issue while using okhttp as mentioned in this : https://github.com/dapr/java-sdk/issues/687

mukundansundar commented 2 years ago

@artursouza What is the Spring Cloud dependency that you mention? cc @skyao

skyao commented 2 years ago

@artursouza What is the Spring Cloud dependency that you mention? cc @skyao

To integrate dapr with spring cloud, since current main version of spring is supporting jdk 1.8 like:

spring cloud v3.x
spring boot v2.x
spring framework v5.x

And for next main version of spring/springboot is required jdk17.

I think most spring users will stay in current spring for a long time because jdk17 and wait for spring new version to be stable.

So, upgrading jdk version of dapr java sdk to jdk11 will bring a risk that if the users are using jdk1.8, then we will loss these users ---- I don't think the user will update to jdk11 just because of dapr.

The best strategy of dapr java sdk is that we can support all of them and let the developer choose one of them:

for jdk1.8, use okhttp3
for jdk11, use httpclient in jdk
customized by the developers if they use other http client in their applications and don't want to introduce a new one.

johnewart commented 2 years ago

@artursouza and I were talking about this earlier and I opened a PR to deprecate the HTTP-transport bits; we could get rid of some code it seems that it could make transitioning easier.

Additionally, we could consider splitting off the HTTP client into its own package/artifact that could be used to keep HTTP support until a project has made the transition away from HTTP (it would also be easier to guarantee you have transitioned your project because removing the -http artifact as a dependency would have no effect)