search

dapr / java-sdk

Dapr SDK for Java
Apache License 2.0
262 stars 207 forks source link

Deprecate Java 8 support and move to Java 11 #626

Closed artursouza closed 7 months ago

artursouza commented 3 years ago

Describe the proposal

Since we already have multiple releases of this SDK supporting Java 8, can we migrate to Java 11 as the minimum JDK version?

This might allow us to migrate to the native HTTP client and move out of OKHTTP, for example. Also, we might consider adopting newer features available in the newer Java language version.

Please, vote with 👍 or 👎

mthmulders commented 3 years ago

In a few days from now, Java 8 will officially be two LTS releases behind. I think the case of replacing OkHttp with the native HTTP client is a good example of the "price" we would pay if we decide to keep on supporting Java 8.

I would be in favour of investigating if the native HTTP client is a suitable replacement for OkHttp. If so, I would vote to drop Java 8 support and set 11 as our new baseline. It's a big move, but we're not alone: Spring 6 will even have Java 17 as its baseline.

A nice additional benefit we can get from this move is that it would also reduce our dependency footprint. This is what we currently add to any project that wants to use the Dapr SDK for Java, because of our dependency on OkHttp:

  \- com.squareup.okhttp3:okhttp:jar:4.9.0:compile
     +- com.squareup.okio:okio:jar:2.8.0:compile
     |  \- org.jetbrains.kotlin:kotlin-stdlib-common:jar:1.4.0:compile
     \- org.jetbrains.kotlin:kotlin-stdlib:jar:1.4.10:compile
        \- org.jetbrains:annotations:jar:13.0:compile
johnou commented 3 years ago

Have you run any relevant benchmarks against native HTTP client and OKHTTP?

artursouza commented 3 years ago

Have you run any relevant benchmarks against native HTTP client and OKHTTP?

No. This replacement would be a follow up on this issue. This would be good data to have to decide on replacing it. If there is a performance penalty, might be worth keeping the OkHTTP dependency.

mthmulders commented 3 years ago

Have you run any relevant benchmarks against native HTTP client and OKHTTP? What kind of setup would we need to gather those benchmarks?

How about this?

  1. a default nginx setup that serves a static response (can even be straight from memory) so we have as little delay on the "server" as possible
  2. run ab to have an idea of how fast that webserver can go
  3. run an OkHttp-based Java program to measure how fast that client is
  4. run an JDK 11 HTTP Client based Java program to measure how fast that client is
  5. compare 2, 3 and 4; assess how much 3 and 4 differ, and how much they each differ from 2
johnou commented 3 years ago

How about turning DaprHttp into an interface, creating two implementations, okhttp and "native" jdk 11 http client then writing / running a performance test using actors with jmh?

artursouza commented 3 years ago

I like the proposals above. Just be mindful that we cannot have client breaking changes in the SDK.

Juliandb1708 commented 3 years ago

To investigate if the Java HTTP client is a suitable replacement for OkHttp in terms of performance, I created a benchmark setup. For the setup I followed the suggestions of @mthmulders and @johnou. The setup is as follows:

  1. default nginx webserver that serves a static JSON response
  2. run ApacheBench to have an idea of how fast that webserver can go (2000 requests)
  3. run Java program with JMH to performance test two implementations (OkHttp and Java HTTP client), both implementing a simplified interface version of the DaprHttp class (2000 requests each)
  4. compare the results of the benchmarks

I ran all the tests on my own machine (with a pretty good processor). So all performance tests ran very fast. I also tried it on a slower machine, which had a visible impact on the speed of the HTTP clients. But relatively this gave the same results. On my own machine this resulted in the following measurements:

I put the setup in a Git repository with clear instructions in the readme, so you can run the benchmark on your own machine too.

artursouza commented 2 years ago

This is excellent work @Juliandb1708. I think the perf difference does not justify adding a (potential) dependency conflict to the applications consuming this SDK. Thoughts?

Vote 🎉 here to use Java HTTP Client. Vote 🚀 here to keep OkHTTP client.

tanvigour commented 2 years ago

/assign

artursouza commented 2 years ago

Please, look at the partial work I have on this. It is moving to Java 11 and removing OKHTTP dependency: https://github.com/artursouza/java-sdk/tree/native_http_client

Pending work:

lburgazzoli commented 1 year ago

I can help with this issue if no one else is looking at it.

I would propose to:

  1. deprecate Java 8 and move to Java 11 (it is already required to build the project)
  2. switch to Java HTTP Client from OkHTTP not needed anymore
skyao commented 11 months ago

I just submitted a proposal to add jdk17 and springboot 3.0 to the dapr java sdk. One of the pending issues is whether continue to support java8.

https://github.com/dapr/java-sdk/issues/971

artursouza commented 7 months ago

We now require JDK 11 as the minimum JDK version.