Though it's currently failing CI and is not complete, but I would like to get opinions on changing the default backing HTTP Client for the RESTEasy REST Client to use the JDK's HttpClient. See the PR [1] for the implementation changes. This is something I've been working off and on again since last December. It feels like it's time to make some decisions before I spend any more time on it :) FWIW it passes for me locally with all profiles on Java 11 on Linux.

One of the big things this gives us would be HTTP/2 support. There are some caveats however. 

One is that the HostnameVerifier cannot be set on the java.net.http.HttpClient. My simple solution to that was to use the old Apache HTTP client if that is the case and log message indicating that.

Another "issue" is that the HttpClient isn't closeable. However, in Java 21 this changes so it might not be a big issue. Jakarta REST 4.0 [2] might require Java 21.

Some tests also required changes. Some only worked with HTTP 1.1 for some reason and others just seemed to require the Apache Client.

I do think a property should be added for a general fallback to the Apache Client. There could be applications that assume the ClientHttpEngine is assumed to be a ApacheHttpClientEngine. We shouldn't require the application to define the engine in the builder each time it creates a client.

In general I'd like to hear what others think about this. I do think having a client that supports HTTP/2 is a must. Either way, we likely break some assumptions about what the default ClientHttpEngine is. Please let me know; good, bad, indifferent or if we should use a different client all together.