java-sdk
java-sdk copied to clipboard
dapr
Replace okhttp with azure core http
Replace this to fix the dependency issue with okhttp3 https://github.com/dapr/java-sdk/issues/687
Please do not use an Azure specific HTTP library. Instead, pick a known Java standard.
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 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
@artursouza What is the Spring Cloud dependency that you mention? cc @skyao
@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.
@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)
