Guava: InternetDomainName.findSuffixOfType() in junit test returns java.lang.NoSuchFieldError: EXACT

[nitrocode]

I'm using guava 24.1-jre and jdk 1.8.0.162

InternetDomainName.from("google.com");

causes

java.lang.NoSuchFieldError: EXACT

    at com.google.common.net.InternetDomainName.findSuffixOfType(InternetDomainName.java:172)
    at com.google.common.net.InternetDomainName.<init>(InternetDomainName.java:153)
    at com.google.common.net.InternetDomainName.from(InternetDomainName.java:212)
    at com.dnb.vici.formfill.common.UtilFunctions.getCustomerAndDomainId(UtilFunctions.java:73)
    at com.dnb.vici.formfill.ut.UtilFunctionsTest.getCustomerAndDomainIdTest(UtilFunctionsTest.java:73)

It's failing on InternetDomainName.java Line #172 and this old storm issue returns a very similar error.

In IntelliJ when I evaluate the expression, it returns false as expected but running through the code will throw the exception and it only happens during a unit test... Why does this happen?

[netdpb]

This looks to me like there is some problem with the Guava in your classpath. PublicSuffixPatterns has existed, and had the field EXACT, since v16. The storm issue mentions shading. Are you shading Guava, and not shading all of the packages? PublicSuffixPatterns is in com.google.thirdparty.publicsuffix.

[nitrocode]

Hi @netdpb thanks for replying. None of the jars are shaded. I'm compiling the app as a fat jar.

I can see the EXACT field is there when I step through the code. I've tried blowing out the ~/.m2/ directory and reinstalling the app. Also tried removing the project from Intellij and re-adding it and I get the same issue.

My workaround has been recently to comment out the unit tests around the issue. 😢

[netdpb]

What else is in your classpath? I cannot replicate this error.

[Stephan202]

The maven-enforcer-plugin has the banDuplicateClasses and requireUpperBoundDeps rules; they can help track down this issue. (There are others, but I suspect one of these will point you in the right direction.)

[nitrocode]

@Stephan202 let me debug this at work on Monday using the tools @Stephan202 provided. I can try to create a mwce if I cannot find the root of it. Thank you!

[nitrocode]

Ok so I found out that this was related to standalone wiremock uses guava version 20.0 and the standalone shades guava. To fix the issue, I reordered the dependencies to make guava load before wiremock and it worked.

    <dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>24.1-jre</version>
    </dependency>

    <dependency>
        <groupId>com.github.tomakehurst</groupId>
        <artifactId>wiremock-standalone</artifactId>
        <version>2.17.0</version>
        <scope>test</scope>
    </dependency>

Is there a better way to debug this kind of dependency conflict in the future?

Thank you for taking the time to help me with this.

[Stephan202]

@nitrocode I'd add the aforementioned checks to your build by default; they could be part of a shared company POM. Others I recommend:

• The maven-enforcer-plugin's dependencyConvergence.
• The maven-dependency-plugin's various analyze* goals.

At Picnic we use a parent which has these and other checks; it ensures that each of our projects has a well-behaved build. (Open-sourcing (a variation of) this pom.xml is on my TODO list, but realistically it's a few months out.)

Edit: actually, most of that parent pom was copied over and open-sourced here. The relevant tidbits are spread across the pluginManagement section section and the build-checks profile.

[nitrocode]

That's awesome, thank you @Stephan202!