Wiremock: Wiremock 2.27.0 breaks compatibility with Android because requires Java 8

[rciovati]

With WireMock 2.27.0 ( configured using a junit rule) our Android tests started failing because with java.lang.NoClassDefFoundError: Failed resolution of: Ljava/nio/file/Paths;. It seems that a recent change introduced the usage of Paths class, which is not available on all versions Android.

Since I don't see this compatibility change being mentioned in the changelog, I'm reporting this problem as an issue to double check that it's an intended change.

[tomakehurst]

Thanks for reporting this. The break wasn't intentional.

Since we build the JRE7 JARs with Java 7, I'm puzzled as to how this slipped through the net.

Anyway, I'll look at putting out a patch release with Paths taken out.

[tomakehurst]

OK, looks like it is in JRE7, but only in Android from API v26 onwards:
https://developer.android.com/reference/java/nio/file/Paths

[tomakehurst]

OK, hopefully fixed this in 2b5087207a8989f3fd989982573305d59f3c753d

@rciovati If I push a staging release, please could you re-test against it?

[rciovati]

@tomakehurst thanks for having a look! sure, I can try that our later today or tomorrow.

[tomakehurst]

Looks like Sonatype have helpfully removed public staging repository URLs, so I've done a full release (under v2.27.1). It might take a little while to sync to m2.

I'll hold off announcing it until I've had some feedback from you.

[rciovati]

Hey, sorry if took a little bit to come back to you.

It seems the error I was getting yesterday is gone but I'm getting another one:

java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/net/ssl/X509ExtendedTrustManager;
at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.addStrategy(SSLContextBuilder.java:99)
at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.addStrategy(SSLContextBuilder.java:93)
at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.loadTrustMaterial(SSLContextBuilder.java:69)
at com.github.tomakehurst.wiremock.http.HttpClientFactory.buildAllowAnythingSSLContext(HttpClientFactory.java:186)
at com.github.tomakehurst.wiremock.http.HttpClientFactory.buildSslContext(HttpClientFactory.java:132)
at com.github.tomakehurst.wiremock.http.HttpClientFactory.createClient(HttpClientFactory.java:94)
at com.github.tomakehurst.wiremock.http.ProxyResponseRenderer.<init>(ProxyResponseRenderer.java:77)
at com.github.tomakehurst.wiremock.core.WireMockApp.buildStubRequestHandler(WireMockApp.java:149)
at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:75)
at com.github.tomakehurst.wiremock.junit.WireMockRule.<init>(WireMockRule.java:43)
at com.github.tomakehurst.wiremock.junit.WireMockRule.<init>(WireMockRule.java:39)

This time it seems that X509ExtendedTrustManager is only available on API Level 24+ (and we're testing down on 23 😕)

[tomakehurst]

Hmmm....

I think this one is going to be harder to fix. Might have to give this some thought over the weekend.

Are you upgrading just in order to track the latest, or because you need a specific feature of 2.27.x?

[rciovati]

Are you upgrading just in order to track the latest, or because you need a specific feature of 2.27.x?

I was upgrading to get the latest release (we do that automatically, that's why I spotted the issue) but at I don't need a specific latest feature and I can stay on 2.26.

[tomakehurst]

I think this may be the last JRE7 compatible release, at least in its current form. The project has become an unholy mess as a result of the dual build targets, and they're starting to diverge quite a bit.

Do you find this with other libraries that aren't Android specific i.e. that they're having to drop support for older API versions or Android entirely?

[Jacks0N23]

Have the same bug after update to 2.27.1
java.lang.NoClassDefFoundError: Failed resolution of: Lorg/apache/http/conn/ssl/NoopHostnameVerifier; at com.github.tomakehurst.wiremock.http.HttpClientFactory.buildSslConnectionSocketFactory(HttpClientFactory.java:105) at com.github.tomakehurst.wiremock.http.HttpClientFactory.createClient(HttpClientFactory.java:95) at com.github.tomakehurst.wiremock.http.ProxyResponseRenderer.<init>(ProxyResponseRenderer.java:77) at com.github.tomakehurst.wiremock.core.WireMockApp.buildStubRequestHandler(WireMockApp.java:149) at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:75) at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:112)

[othmanelkourd]

I have the same in Android after updating to 2.27.2

java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/net/ssl/X509ExtendedTrustManager; at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.addStrategy(SSLContextBuilder.java:99) at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.addStrategy(SSLContextBuilder.java:93) at com.github.tomakehurst.wiremock.http.ssl.SSLContextBuilder.loadTrustMaterial(SSLContextBuilder.java:69) at com.github.tomakehurst.wiremock.http.HttpClientFactory.buildAllowAnythingSSLContext(HttpClientFactory.java:186) at com.github.tomakehurst.wiremock.http.HttpClientFactory.buildSslContext(HttpClientFactory.java:132) at com.github.tomakehurst.wiremock.http.HttpClientFactory.createClient(HttpClientFactory.java:94) at com.github.tomakehurst.wiremock.http.ProxyResponseRenderer.<init>(ProxyResponseRenderer.java:77) at com.github.tomakehurst.wiremock.core.WireMockApp.buildStubRequestHandler(WireMockApp.java:149) at com.github.tomakehurst.wiremock.WireMockServer.<init>(WireMockServer.java:75)

[TWiStErRob]

We releasing down to API 21 and usually UI testing with API 24. You claimed 24 support in 2.27.1, but the above 2 exceptions are preventing usage. What can we do here? Are we stuck on 2.26.x?

@tomakehurst: Do you find this with other libraries that aren't Android specific i.e. that they're having to drop support for older API versions or Android entirely?

Nope, there's usually feature detection and abstraction for these things. I think OkHttp is a good example, see https://github.com/square/okhttp/tree/master/okhttp/src/main/kotlin/okhttp3/internal/platform

[tomakehurst]

I would suggest dropping back to 2.26.x for now.

As I mentioned in the earlier comment, I'm not going to release the JRE7 JAR under 2.x any more, but want to come up with a proper compatibility strategy of the OkHttp variety from 3.x onwards.

I'm going to make a proper announcement about this soon, but my intention is to try and recruit someone willing to step up as the WireMock Android lead (please let me know if you or colleagues are interested!). I'll then work with that person (and the Android WireMock user community in general) to define an new architecture that properly abstracts the platform-specific parts and produce a dedicated Android artifact.

[yogurtearl]

OkHttp has almost no dependencies (just okio and kotlin stdlib)

That makes it much easier to support Android.
As you know, one of the biggest challenges with supporting Android in wiremock will be making sure dependencies don't use any Java 8 APIs and don't use java.nio.file APIs.

Will Wiremock 3.x have significantly different deps from 2.x? are the plans for 3.x written anywhere?
Maybe crazy talk, but netty can run on JDK 6, is basing wiremock on netty out of the question?

[tomakehurst]

I've posted this elsewhere, but I'll restate it here: I'm only going to maintain the jre8 build in the 2.x line from now on (2.28.0 will be the first release without the JRE7 JARs), and use 3.x for a major rethink around Android support.

A key part of that will be abstracting the parts where different impls make sense on different platforms, and that'll certainly include the web server (actually this is already swappable, but no alternative impls exist yet) and the HTTP client.

With this extra modularity it should hopefully be possible to maintain a dedicated Android JAR, rather than merely a JDK7 JAR that kinda works OK.

I'll put up a placeholder issue soon as a place to discuss how this could work, and I'll be sure you tag you @yogurtearl!

So, with all that in mind, I'm going to close this issue.

[TWiStErRob]

@tomakehurst please link that issue here too, so other watchers are notified, thanks.