java.lang.NoSuchMethodError exception, caused by dependency conflict with Guava in truth/extensions/liteproto

[LeoAugust19]

Hi, dependency conlict issue exists in truth/extensions/liteproto. As shown in the following dependency tree, this project directly depends on com.google.guava:guava:jar:23.6, and transitively depends on com.google.guava:guava:jar:25.1, based on Maven's loading mechanism, the old version wins the newer one.

Dependency tree:
com.google.truth.extensions:truth-liteproto-extension:jar:0.41
+- com.google.truth:truth:jar:0.41:compile
| +- (com.google.guava:guava:jar:25.1-android:compile - omitted for conflict with 23.6-android)
+- com.google.guava:guava:jar:23.6-android:compile

However, method com.google.common.base.Strings.lenientFormat(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String is referenced by the host project and only defined in guava:jar:25.1, which causes the java.lang.NoSuchMethodError exception.

When executing the following test case, we got the stack trace:

Test case:

LiteProtoTruth.assertThat(UnknownFieldSet.getDefaultInstance()).isEqualTo(new Object());

Stack trace:

Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.base.Strings.lenientFormat(Ljava/lang/String;

[Ljava/lang/Object;)Ljava/lang/String;
at com.google.common.truth.Subject.failWithRawMessage(Subject.java:1043)
at com.google.common.truth.extensions.proto.LiteProtoSubject.isEqualTo(LiteProtoSubject.java:106)
at com.google.common.truth.extensions.proto.Test.main(Test.java:11)

The solution is to update com.google.guava:guava:jar:23.6 to 25.1 to make the version consistent.

Hope this report can help you. Thanks! ^_^

[cpovirk]

Thanks and sorry. I will get together a fix.

[cpovirk]

I got to wondering how this passed our tests, and:

truth/extensions/liteproto/pom.xml

Line 22 in 36140ea

<maven.test.skip>true</maven.test.skip>

[cpovirk]

Fix released in Truth 0.42.

[Nyeng]

Not sure if this is the same thing, but I get the same error message from this:

 assertWithMessage("Strings are not equal")
            .that("asd")
            .isEqualTo("test");

java.lang.NoSuchMethodError: com.google.common.base.Strings.lenientFormat(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String;
When I change the test to pass the error doesn't happen.

[cpovirk]

That sounds like at least a similar problem. If you're using Truth 0.41, you can try upgrading to 0.42 and seeing if that helps. If not, you may need to manually force Maven (or whatever build system you're using) to pull in version 25.1 of Guava, typically with something like...

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

It may be possible to detect potential such problems (where a newer version of a dependency is overridden by a newer one) by using requireUpperBoundDeps.

[cpovirk]

From my perspective, either one is sufficient.

I am particularly interested in the static analysis, though: It seems like it would have the potential to identify more problems more easily. That could include problems from combining two different libraries that request different versions of a common dependency. If you ever have a tool that we can run continually on Truth and other Google projects, or if you have other information to share, I'd be happy to hear about it :)

[LeoAugust19]

Hi, @cpovirk, If available, could you please send me an Email (2339788768@qq.com), because I didn't find your contact information. We developed a tool that can automatically detect the dependency conflict (DC) issue using static analysis. We hope that you can try out our tool and give us some suggestions to improve it. We look forward to cooperating with you to perfect this tool and using it to run continually on Google projects and other open source community projects. After all, ensuring the projects’ long-term health and improve their maintainability is our common aspiration.

[cpovirk]

Thanks! I was OOO for a few months, and now I'm playing catchup, but I've pointed some teammates to this message. They'll have a better idea of whether they can be in touch anytime soon.