okhttp3.tls.HandshakeCertificatesTest.clientAndServer is failing on recent OpenJDK 8

[bemasc]

With OpenJDK 8u181 on Debian, I'm seeing this test failing with a NoSuchMethodError. After adding some debug logs I see this error trace:

java.lang.NoSuchMethodError: sun.security.ssl.SSLSessionImpl.<init>(Lsun/security/ssl/ProtocolVersion;Lsun/security/ssl/CipherSuite;Ljava/util/Collection;Ljava/security/SecureRandom;Ljava/lang/String;IZ)V
        at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:787)
        at sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:232)
        at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1052)
        at sun.security.ssl.Handshaker.process_record(Handshaker.java:987)
        at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1072)
        at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
        at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
        at okhttp3.tls.HandshakeCertificatesTest$1.call(HandshakeCertificatesTest.java:167)
        at okhttp3.tls.HandshakeCertificatesTest$1.call(HandshakeCertificatesTest.java:156)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
        at java.lang.Thread.run(Thread.java:748)

This is consistent with a reported bug in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8213936. The bug was first reported about a month ago but there hasn't been any progress on it yet.

[swankjesse]

Are you using Jetty-ALPN for HTTP/2 ?

[bemasc]

I'm just running "mvn clean test" in a checkout of master on Debian buster/sid. I don't know enough about okhttp to understand your question.

[swankjesse]

Gotcha. HTTP/2 requires a bootclasspath hack for platforms through Java 8 and that's likely what's breaking here.

Best workaround is upgrading to Java 11. Conscrypt is another fix. Avoiding HTTP/2 also avoids this.

[yschimke]

I wonder whether alpn-boot missed a change they need to build against

https://www.eclipse.org/jetty/documentation/9.4.x/alpn-chapter.html#alpn-versions

[yschimke]

Debian specific based on discussion in jetty-project/jetty-alpn#26 (comment)