voucherifyio/voucherify-java-sdk

Backward Compatibility With okhttp3 3.14.x

ausykaso opened this issue · 6 comments

ausykaso commented

Problem:

  • If the voucherify-java-sdk is used together with the current Contentful Java SDK there's a version clash regarding okhttp3: voucherify depends on version 4.2.0 and contentful on 3.12.12.
  • At compile time, the build tool (in our project gradle) negotiates okhttp3 version 3.14.9 as the most suitable version to be used for both.
  • The project using both, voucherify and contentful builds without errors or warnings but then fails at runtime in VoucherifyClient.java:245 with an invalid method call exception (access to a private member).
  • Using voucherify 8.1.0 (latest version before switching to okhttp3 4.2.0) works but fails reading vouchers from the predefined voucherify 30 day trial environment -> versions after 8.1.0 seems to introduce breaking changes, error message: 
    "io.voucherify.client.error.VoucherifyError: Cannot deserialize value of type  io.voucherify.client.model.voucher.DiscountType from String "FIXED": not one of the values accepted for Enum class: [AMOUNT, UNIT, PERCENT]"

Expected behaviour:

  • Either a project using the voucherify SDK 9.x or higher must not compile if an incompatible version of one of the voucherify dependencies has been negotiated by the build tool
  • Or voucherify should be backwards compatible (to a defined version?)
ausykaso commented

Changing/Fixing Voucherify's SDK by changing VoucherifyClient.java:245

httpLoggingInterceptor.level(
httpLoggingInterceptor.setLevel(

makes the PoC running with okhttp 3.14.9 (test with fetching a voucher).

tpindel commented

Hi @ausykaso, we are considering releasing the following version to fix your case -> #105

Nevertheless, we don't fill comfortable with switching the version of okhttp3 to the older one only due to the fact that Contentful uses some old ones.

ausykaso commented

i @tpindel, thx for your quick reply! I agree totaly to your concerns regarding backwards compatibility that other components does not keep their dependencies up to date! It's more a nightmare for us not to be able to use current (stable and safe) versions of our components. Anyhow, at least incompatibilities should fail at compile- not at runtime (what's also a nightmare). If instead backwards compatibility will be provided - it would be the fastest and most easiest solution. And I agree, not the best one.

  • 👍1
ausykaso commented

In case of the Voucherify SDK should be used in a Spring Boot application you should consider https://docs.spring.io/spring-boot/docs/2.5.6/gradle-plugin/reference/htmlsingle/#managing-dependencies.dependency-management-plugin.customizing - Spring Boot dependency management defines okhttp3 version 3.4.19 as a default and does not recommend to change that version -> anyhow, there is no hard dependency from any Spring Boot component to that okhttp3 version. In a pure Spring Boot project you might also use okhttp3 4.9.0.
But I assume, that any other component, that want to run with Spring Boot, will not refer to other versions than recommended by Spring Boot as a default. That unfortunately prevents to upgrade those components ...

tpindel commented

@ausykaso Please leave your comments in Pull Request if you have any suggestions on that topic: https://github.com/voucherifyio/voucherify-java-sdk/pull/105/files

tpindel commented

@lkulig Did we release the new version with enhancements covering issues reported in that ticket?