This is because Undertow is testing SPDY and HTTP2, which use Jetty ALPN. This jar resides on the boot class path, and you need to use a specific version of it for a given JVM. Undertow uses profiles to select between JDK 7 and 8, however it looks like it will attempt to use the 8 jar if you test on 9. I will look at updating the build to just ignore these tests if the appropriate version of the ALPN jar is not available. Stuart Bernd Eckenfels wrote: > Hello JDK security team, > (cced the Undertow guys cause I mentioned this on the IRC channel) > > > when trying to run the JBoss Undertow build tests with JDK9ea-b30 a > lot of tests fail with the same "NosuchMethodError", and I am not > sure why. > > It looks like an internal inconsitency in the JSSE? However I tries > the simple SSLEngine demo code and that one compiles and runs. > > Undertow master 79daf29 > https://github.com/undertow-io/undertow/tree/79daf29322940f93a42f736a2cd9... > > maven 3.2.3 Windows x64 7 > this is using xnio-api and xnio-nio 3.3.0.Beta3 (from > jboss-public-repository-group) > > > One of the observed exceptions (but not related to SPDY IMHO): > > 03:26:29,211 ERROR (XNIO-1 I/O-2) > [org.xnio.listener]<ChannelListeners.java:94> XNIO001007: A > channel event listener threw an exception: > > java.lang.NoSuchMethodError: > sun.security.ssl.ClientHandshaker.getRawHostnameSE()Ljava/lang/String; > at > sun.security.ssl.ClientHandshaker.getKickstartMessage(ClientHandshaker.java:1294) > at sun.security.ssl.Handshaker.kickstart(Handshaker.java:972) at > sun.security.ssl.SSLEngineImpl.kickstartHandshake(SSLEngineImpl.java:728) > at > sun.security.ssl.SSLEngineImpl.beginHandshake(SSLEngineImpl.java:750) > > at > org.xnio.ssl.JsseSslConduitEngine.beginHandshake(JsseSslConduitEngine.java:177) > at > org.xnio.ssl.JsseSslStreamConnection.startHandshake(JsseSslStreamConnection.java:85) > at > io.undertow.client.spdy.SpdyClientProvider.handlePotentialSpdyConnection(SpdyClientProvider.java:222) > at > io.undertow.client.http.HttpClientProvider.handleConnected(HttpClientProvider.java:132) > at > io.undertow.client.http.HttpClientProvider.access$000(HttpClientProvider.java:49) > at > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:123) > at > io.undertow.client.http.HttpClientProvider$2.handleEvent(HttpClientProvider.java:120) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:283) > at > org.xnio.ssl.JsseXnioSsl$StreamConnectionChannelListener.handleEvent(JsseXnioSsl.java:265) > at > org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at > org.xnio.nio.WorkerThread$ConnectHandle.handleReady(WorkerThread.java:324) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:539) > > > As xnio (the NIO abstraction used by undertow) uses asm and some > unsafe functions it might not be the cleanest test, however the > stacktrace looks like the problem is all inside javax.ssl / JSSE? > > I am not sure where to look for the right JDK source version, is > this before or after the modular split? The latest code does not > seem to match the stacktrace: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/40c3a5ce8047/src/java.base/... > > Gruss > Bernd > > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev