Guava version conflicts - NoSuchMethodError

I’m getting the following exception using Guava v23 and Reflections v0.9.11.

Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.collect.Sets$SetView.iterator()Lcom/google/common/collect/UnmodifiableIterator;
	at org.reflections.Reflections.expandSuperTypes(Reflections.java:380)
	at org.reflections.Reflections.<init>(Reflections.java:126)
	at org.reflections.Reflections.<init>(Reflections.java:168)
	at org.reflections.Reflections.<init>(Reflections.java:141)
        ...

Going back to Reflections v0.9.10 fixes the problem, since it was compiled for Guava v15, which seems to be somehow compatible with Guava v23 but not with v20 (version used in Reflections v0.9.11).

Any chance to update this lib to use Guava v23 in future releases? That would fix the problem once and for all.

[Flexximilian]

Same here, and everywhere, really. Just google the error. Guava is evil.

They change things in a binary incompatible way without any regard to the trouble they cause, or the cost they create. Now that’s fine for internal packages, but not for something they put out without warning that such is their governance model. Newer versions break existing code built against older versions, all in the same classes and packages (unlike Apache commons, who make very sure that code doesn’t break, and if it does it goes in a separate package. Hence lang3 and collections4, etc.). It’s very easy to end up with a maven dependency tree of software requiring guava versions containing methods that are mutually existent/non-existent in different versions. So not even a rebuild can fix the mess. There is no chance of fixing this if two such pieces of code are 3rd party libraries depending on guava. If you’re lucky, one of the libraries is open source with a permissive licence where a fork is an option.

I’d vote for reflections to ditch the dependency on guava altogether.

[jshook]

Any chance we could simply remove the guava dependency and use other options from Java 8, for example? The broken version dependencies in guava have caused significant pain in downstream projects, requiring shading and other techniques. It is difficult to need the functionality of this library but to have to micromanage around guava dependencies from multiple projects at the same time.

I’ve started removing guava from all my top-level projects in order to simplify builds back down. It would be really great if I didn’t have to include it for reflections too.