HTTP/2 Client — Incubation to Standardisation

You must be aware that a number of existing HTTP client APIs and implementations exist, e.g. Jetty and the Apache HttpClient. But then they are 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, reactive programming etc.

Most of us have given a try to HTTP/2 introduced with Java-9 release as an incubating feature.

Now that the standardisation of the API is available with the early access builds for JDK/11, here are few highlights one must be aware of while planning to migrate to the LTS of JDK and continuing to work with the HTTP APIs.

1. Find & Replace—

Modularized libraries could have made use of the incubated module using a `requires` directive since the release of Java-9 as follows:

module com.stackoverflow.nullpointer {
    requires jdk.incubator.httpclient;
}

Now, all that these libraries would need to change, while migrating to JDK/11 and continuing to using the HTTP module further is renaming `jdk.incubator.httpclient` to `java.net.http` in their module declarations and the result —

module com.stackoverflow.nullpointer {
    requires java.net.http;
}

2. Wonders happening themselves —

Applications, frameworks(like Maven, Gradle etc) or IDEs relying on the classpath would no more need to set the:

--add-modules jdk.incubator.httpclient

command-line option to request the incubator module to be resolved. Being a standard module the `java.net.http` module shall be resolved by default.

Additionally, the standardisation also throws away the warnings(no more now) issued at compile time, link time, and run time whenever the incubator module was resolved. No wonder all of this automatically solves :

• NoClassDefFoundError while trying to use jdk.incubator.http.HttpClient in java in Eclipse Oxygen
• HttpClient at Runtime throws java.lang.NoClassDefFoundError: jdk/incubator/http/HttpClient
• Using Incubator Http Classes with Maven in Java9

3. Icing on top of the Cake —

Back-pressure and flow-control of request and response bodies in the HTTP module is implemented using the Flow APIs introduced in Java-9 based on the the reactive-streams.

The final implementation is completely asynchronous while the previous HTTP/1.1 implementation was blocking. Use of the RX Flow concept has been pushed down into the implementation, which eliminated many of the original custom concepts needed to support HTTP/2.

The flow of data can now be more easily traced, from the user-level request publishers and response subscribers all the way down to the underlying socket. This significantly reduces the number of concepts and complexity in the code, and maximizes the possibility of reuse between HTTP/1.1 and HTTP/2.

All that looks interesting? Just got to wait for the final release of JDK/11 until 2018/09/25 for its general availability and moving your code to production. Until then keep trying your hands on the Early access builds and make use of the `java.net.http` module.