JEP 110: HTTP 2 Client

OwnerMichael McMahon
Created2014/05/12 16:26
Updated2015/02/05 20:38
Componentcore-libs /
Discussionnet dash dev at openjdk dot java dot net
Reviewed byAlan Bateman
Endorsed byBrian Goetz


Define a new HTTP client API that implements HTTP 2.0 and can replace the legacy HttpURLConnection API.


The existing HttpURLConnection API and its implementation have numerous problems:



This API is intended to replace the HttpURLConnection API for new code, but we do not intend immediately to re-implement the old API using the new API. This may happen as future work.

Some requirements were considered in earlier versions of this JEP for JDK 8, but they are being left out in order to keep the API as simple as possible:

Some of these requirements, e.g., connection caching, will become less important with the gradual adoption of HTTP 2.0.


Some prototyping work was done during JDK 8 in which separate classes were defined for the HTTP client, requests, and responses. The builder pattern was used to separate mutable entities from the immutable products. The prototype was built on NIO AsynchronousSocketChannels and that API will be the starting point for this work. It is expected that the API will undergo a number of iterations before being finalised. The prototype implementation was standalone, i.e., the existing stack was not changed so as to ensure compatibility and allow a phased approach in which not all functionality must be supported at the start.

The prototype API also included:


A number of existing HTTP client APIs and implementations exist, e.g., example Jetty and the Apache HttpClient. Both of these are both rather heavy-weight in terms of the numbers of packages and classes, and they don't take advantage of newer language features such as lambda expressions.

Risks and Assumptions

HTTPS 2.0 support depends upon TLS ALPN (Application Layer Negotiation Extension) which is not currently supported in the JDK.

The HTTP 2.0 spec itself is still in internet-draft form, but is expected to be submitted as a draft standard in November 2014.


The internal HTTP server will provide a suitable basis for regression and TCK tests. Functional tests could use that also, but they may need to test against real HTTP servers.