When using JDKs based on OpenJDK 8 (for JDK 9 see above), and you do not or cannot use Conscrypt, you can use Jetty’s ALPN boot library to provide the ALPN service implementation, via the alpn-boot artifact.

The Jetty ALPN boot library modifies the relevant OpenJDK classes to add ALPN support and provides an ALPN API that application can use to enable ALPN.

When using Jetty as a standalone server via the Jetty distribution, ALPN support is automatically enabled when the http2 module is enabled. This enables transitively the alpn-8 module which puts the jetty-alpn-openjdk8-server artifact in the server classpath, providing the ALPN OpenJDK 8 service implementation.

When using Jetty embedded, the ALPN support is provided by the jetty-alpn-openjdk8-client and jetty-alpn-openjdk8-server artifacts, respectively for client usage and server usage.

To get ALPN working with the Jetty ALPN Boot library, you need:

Start the JVM as follows:

java -Xbootclasspath/p:<path_to_alpn_boot_jar> ...

Where path_to_alpn_boot_jar is the path on the file system for the alpn-boot artifact, such as the one at the Maven coordinates org.mortbay.jetty.alpn:alpn-boot.

Be certain to get the ALPN boot artifact version that matches the version of your JRE.

When using JDK 8 or later, you can use the Conscrypt security provider to provide the ALPN service implementation.

Conscrypt binds natively to BoringSSL (a fork of OpenSSL by Google), so ALPN will be supported via the support provided by BoringSSL (bundled together with Conscrypt).

When using Jetty as a standalone server via the Jetty distribution, ALPN is enabled by enabling the conscrypt module.

When using Jetty embedded, ALPN is enabled by the jetty-alpn-conscrypt-client and jetty-alpn-conscrypt-server artifacts, respectively for client usage and server usage. In addition, you also need the Conscrypt artifacts, typically the org.conscrypt:conscrypt-openjdk-uber artifact. All these artifacts must be added to the classpath.

When using JDK 9 or later and Jetty as a standalone server via the Jetty distribution, ALPN support is automatically enabled when the http2 module is enabled. This enables transitively the alpn-9 module which puts the jetty-alpn-java-server artifact in the server classpath, providing the ALPN JDK 9 service implementation.

When using JDK 9 or later and Jetty embedded, the ALPN service implementation is provided by the jetty-alpn-java-client and jetty-alpn-java-server artifacts, respectively for client usage and server usage, and must be added to the classpath.

When starting the Jetty server, especially when using Jetty embedded, it may be possible that you see an error similar to this:

IllegalStateException: no ALPN processor

The error means that you don’t have the ALPN dependencies setup correctly in your classpath.

For example, you may have the jetty-alpn-java-server artifact in the classpath (which is correct when using JDK 9), but run your application with JDK 8.

Another example is when you have correctly put the alpn-boot artifact in the boot classpath, but you don’t have the jetty-alpn-openjdk8-server artifact in the classpath.

The following sections only refer to the API and implementation of ALPN using the Jetty boot library.

The Jetty ALPN boot library is conceptually made of two parts: the ALPN APIs and the ALPN implementation.

The ALPN API is provided by the org.eclipse.jetty.alpn:alpn-api artifact. This artifact is only needed by application code that uses the ALPN APIs.

The ALPN implementation is provided by the org.mortbay.jetty.alpn:alpn-boot artifact and consist of modifications to the OpenJDK classes. The org.mortbay.jetty.alpn:alpn-boot artifact contains also the classes present in the org.eclipse.jetty.alpn:alpn-api artifact.

SSLContext sslContext = ...;
SSLSocket sslSocket = (SSLSocket)context.getSocketFactory().createSocket("localhost", server.getLocalPort());

ALPN.put(sslSocket, new ALPN.ClientProvider()
{
    @Override
    public List<String> protocols()
    {
        return Arrays.asList("h2", "http/1.1");
    }

    @Override
    public void unsupported()
    {
        ALPN.remove(sslSocket);
    }

    @Override
    public void selected(String protocol)
    {
        ALPN.remove(sslSocket);
        System.out.println("Protocol Selected is: " + protocol);
    }
});

The ALPN implementation calls ALPN.ClientProvider methods protocols(), unsupported() and selected(String), so that the client application can:

The example for SSLEngine is identical, and you just need to replace the SSLSocket instance with an SSLEngine instance.

SSLEngine sslEngine = ...;
ALPN.put(sslEngine, new ALPN.ServerProvider()
{
    @Override
    public void unsupported()
    {
        ALPN.remove(sslEngine);
    }

    @Override
    public String select(List<String> protocols);
    {
        ALPN.remove(sslEngine);
        return protocols.get(0);
    }
});

The ALPN implementation calls ALPN.ServerProvider methods unsupported(), and select(List<String>), so that the server application can:

It is important that implementations of ALPN.ServerProvider and ALPN.ClientProvider remove the sslSocket or sslEngine when the negotiation is complete, like shown in the examples above. Failing to do so will cause a memory leak.

You can write and run unit tests that use the ALPN implementation. The solution that we use with Maven is to specify an additional command line argument to the Surefire plugin:

<project>

<properties>
    <alpn-boot-version>8.1.4.v20150727</alpn-boot-version>
</properties>

<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <configuration>
                <argLine>
                    -Xbootclasspath/p:${settings.localRepository}/org/mortbay/jetty/alpn/alpn-boot/${alpn-boot-version}/alpn-boot-${alpn-boot-version}.jar
                </argLine>
            </configuration>
        </plugin>

        ...

    </plugins>
</build>

...

</project>

You can enable debug logging for the ALPN implementation in this way:

ALPN.debug = true;

Since the ALPN class is in the boot classpath, we chose not to use logging libraries because we do not want to override application logging library choices; therefore the logging is performed directly on System.err.

The ALPN implementation relies on modification of a few OpenJDK classes and on a few new classes that need to live in the sun.security.ssl package. These classes are released under the same GPLv2+exception license of OpenJDK.

The ALPN class and its nested classes are released under same license as the classes of the Jetty project.

The ALPN implementation, relying on modifications of OpenJDK classes, updates every time there are updates to the modified OpenJDK classes.

This section is for Jetty developers that need to update the ALPN implementation with the OpenJDK versions.

Clone the OpenJDK repository with the following command:

$ hg clone http://hg.openjdk.java.net/jdk8u/jdk8u jdk8u
$ cd !$
$ ./get_source.sh

To update the source to a specific tag, use the following command:

$ ./make/scripts/hgforest.sh update <tag-name>

The list of OpenJDK tags can be obtained from this page: OpenJDK 8 Tags.

You will then need to compare and incorporate the OpenJDK source changes into the modified OpenJDK classes at the ALPN GitHub Repository, branch master.