Comment From: bclozel

See spring-projects/spring-boot#18506 for background.

Looking at the requirements section of the okhttp docs, it seems that we shouldn't expect backports on the 3.x branch from now on. This means we have two choices for Spring Framework 6.0:

  • upgrade our OkHttp3ClientHttpRequestFactory to 4.x, a breaking change with kotlin being mandatory
  • deprecate this implementation in 5.3.x and remove it in 6.x

With the Kotlin requirement and the direction the project is taking, I think we should review this use case completely. From my understanding, WebClient makes more sense as an HTTP client from a Kotlin perspective.

Comment From: larsgrefer

We are already using OkHttp 4 with RestTemplate in our Spring Boot 2.x applications. This works, because OkHttp 4 is binary compatible to OkHttp 3. Our applications are written in Java, but we don't mind having kotlin-stdlib on our classpath.

With spring-projects/spring-boot#18506 in mind I thought Spring Framework 6 (and Boot 3) would be the right place and time to make this major update of OkHttp.

  • upgrade our OkHttp3ClientHttpRequestFactory to 4.x, a breaking change with kotlin being mandatory

I personally don't mind having kotlin-stdlib on my classpath. In theory Spring Framework could stay compatible with both OkHttp 3.x and 4.x, but - as you said - 3.x doesn't get many backports anymore, so most (new) applications should use 4.x anyway.

  • deprecate this implementation in 5.3.x and remove it in 6.x

I don't see a good reason why OkHttp support should be removed. As an application developer I'd like to decide myself if the transitive dependency on kotlin-stdlib is a trade-off I am willing to take or not.

Comment From: jhoeller

@bclozel with OkHttp 4.x remaining binary compatible with OkHttp 3 (just deprecating a few methods but keeping them around as pointed out above), we also got the option of sticking with an OkHttp 3.14.9 baseline for compilation in spring-web - and keeping up runtime compatibility against OkHttp 4.x, possibly with dedicated tests in a separate module that runs our tests against OkHttp 4.9.3.

In any case, I'm not in favor of a general OkHttp 4 baseline on our end (at the core framework level). The majority of existing applications will be using OkHttp 3.14 with regular Java still (initially at least), so retaining compatibility there seems sensible, and the easiest enforcement is to keep compiling against the common OkHttp 3.14 API (seeing it as a Java API jar to compile against, not necessarily as a suggested runtime dependency version). On a separate note, Spring Boot 3 may decide to go with OkHttp 4.9.3 as its managed version or even drop OkHttp dependency management completely.

And if we ever decide to deprecate OkHttp support in spring-web altogether, we can still do so within the Spring Framework 6.x generation. Within 5.3.x, I'd rather avoid a deprecation step at this point.

Comment From: bclozel

Thanks @jhoeller - I'm closing this PR as a result. We'll keep this arrangement around for the time being and we might revisit it in the 6.x timeframe.

We'll defer to the Spring Boot team on the auto-configuration and dependency management decisions.

Thanks @larsgrefer for the contribution!