Servlet 4.0 Leads To

The Servlet API is one of the most used API, if not the most used API of the Java EE Platform! It was revised for Java EE 7, Servlet 3.1 (JSR 340) added quite some new capabilities such as support for the HTTP 1.1 upgrade mechanism (required for supporting WebSocket for example), non-blocking asynchronous IO, various security related improvements and so on.

The primary goal of this JSR is to expose support for the upcoming IETF standard HTTP/2 to users of the Servlet API. A secondary goal is to refresh the Servlet API with to achieve compliance with new features in HTTP 1.1 as well as responding to community input.
HTTP/2 is still in active development in an IETF working group (WG), however, it is expected to be completed well in advance of the completion date of Java EE 8. While it is generally a bad idea to track a moving target such as an actively developed IETF specification, several factors mitigate the risk in this case.

HTTP/2 is heavily based on the SPDY prototype from Google. This prototype appears to have the backing of the WG in addition to the full support of Google.
Browser support for SPDY is widespread with Chrome, Firefox, Safari, and Internet Explorer already present.
The Java EE 8 JSRs are slated for proposed final draft in Q4CY2015. If HTTP/2 isn"t done by then, something drastic will have gone wrong.
As HTTP/2 is the main driver for Servlet 4.0, it is safe to state some of its goals as our goals:
Substantially and measurably improve end-user-perceived latency in most cases over HTTP 1.1 using TCP.
Do not require multiple connections to a server to enable parallelism, thus improving the use of TCP especially regarding congestion control. The following features from HTTP/2 are expected to be exposed by the Servlet 4.0 API:

Moving from 3.1 to 4.0 clearly means that this will be a major revision of the Servlet specification and it has a key theme, i.e. HTTP/2. It will be the first new version of the HTTP protocol since the current version (HTTP 1.1) which was standardized ... end of the last century (RFC 2616)! HTTP/2 will bring many improvements over HTTP/1.x. In his draft proposal, Shing Wai lists the HTPP/2 features that he expects to be exposed by the Servlet 4.0 API:

Request/Response multiplexing
Stream Prioritization
Server Push
Upgrade from HTTP 1.1

The HTTP/2 specification includes:

Request/response multiplexing - each TCP connection is fully bi-directional
Binary framing - HTTP/2 is a binary protocol, which makes makes the framing much easier. Determining the start and end of frames is complicated with a text-based protocol, such as HTTP/1.1. Binary framing also solves the HOL blocking problem
Stream prioritisation - each stream has a priority, which can be used to the tell the peer which streams are considered most important
Server push - this allows the server to populate the browser’s cache in advance of the browser asking for resources
Header compression (known as HPACK) - a compression format for efficiently representing HTTP header fields
HTTP/2 upgrade from HTTP/1.1 - including the definition of protocol upgrade with transport layers that are both non secure (using port 80 and HTTP status code 101 ‘Switching Protocols’) and secure (using NPN or ALPN)