Why isn't java.net.HttpClient the default connector? 🤔

[mkarg]

Since Java 11 there is java.net.HttpClient. It looks as if it could provide superior throughput over HttpUrlConnection, as it supports HTTP/2 for example. I wonder what are the actual reasons why still HttpUrlConnection is used as the default connector but not java.net.HttpClient? 🤔

[jansupol]

Unfortunately, the java.net.HttpClient is not a very OPEN HTTP client implementation. The modification possibility to the HTTP behaviour is limited. The classes are closed, usually in an internal (jdk.*) package, and unable to be extended. Also, most customers want to set all the options per request, and the HttpClient sets most properties on HttpClient.Builder class, i.e. on the client before the request.

Also, we have a problem with mandatory Multipart support. The problem is that the multipart changes the HTTP headers from the multipart writer (which in general is not a problem for multipart only, but for any changes made from a Writer, which is supported by JAX-RS Spec.) , i.e. when the request is created. But when the request is created by HttpRequest.Builder#build(), it is already immutable. The writer needs the request for having its OutputStream.

We made some performance tests, and the default connector seems to have a slightly better result.

It has the advantage of HTTP/2 support (although there are some non-implemented HTTP/2 use-cases), and HTTP PATCH, but overall, it does not look as good as we would like to have it.