# Why libraries like Guava need more than POMs

DevFeed: [Why libraries like Guava need more than POMs](<https://devfeed.tech/articles/why-libraries-like-guava-need-more-than-poms-24639.md>)

Original publisher: [Read original article](<https://blog.gradle.org/guava>)

Author: Jendrik Johannes

Published: 2020-01-22T05:00:00Z

Content type: tutorial

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Dependency management](<https://devfeed.tech/topics/dependency-management.md>), [Gradle](<https://devfeed.tech/topics/gradle.md>), [Java](<https://devfeed.tech/topics/java.md>), [Maven](<https://devfeed.tech/topics/maven.md>), [Graphs](<https://devfeed.tech/topics/graphs.md>), [Google](<https://devfeed.tech/topics/google.md>)

Tags: [dependencies](<https://devfeed.tech/tags/dependencies.md>), [dependency-management](<https://devfeed.tech/tags/dependency-management.md>), [google](<https://devfeed.tech/tags/google.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [graph](<https://devfeed.tech/tags/graph.md>), [java](<https://devfeed.tech/tags/java.md>), [libraries](<https://devfeed.tech/tags/libraries.md>)

## AI overview

This article explains why widely adopted Java libraries such as Google Guava can create dependency conflicts that ordinary POM metadata and dependency-management engines may not detect. It examines Guava's naming and versioning history and presents Gradle Module Metadata as a way to avoid these problems.

## Source excerpt

More than 10 years ago, a new Java collections library was released by Google. This library, now known as Google Guava, would gain a lot of traction over the months and years and is possibly the most used Java library in production code today. Due to the widespread adoption of Guava, many other libraries depend on it today. Chances are high that you will find it on the classpath of any reasonably large Java project through transitive dependencies, even if it is not used directly. With more and more code depending on such a widely used library, the potential for conflicts increases, adding to a project's dependency hell. Consider the following harmless-looking dependency declaration block: dependencies { implementation("com.google.guava:guava:28.0-jre") implementation("org.codehaus.plexus:plexus-container-default:2.1.0") implementation("com.google.api-client:google-api-client:1.30.7") } We would expect to end up with a JRE (and not an Android) variant of Guava and we would expect the build tool to inform us if there are other suspicious conflicts on our classpath. Let's take a look at a build scan showing the dependencies graph: If we look closely, we can observe some unexpected things: Why was guava:28.0-jre, replaced with guava:28.1-android without warning? Why is there a google-collections dependency - wasn't that the same as Guava? Why do I need j2objc-annotations on my runtime classpath? And what is this weird 9999.0-empty-to-avoid-conflict-with-guava dependency? To understand this, we will discuss the dependency management challenges that appeared during the evolution of Guava and how they were handled. In the end, we will show how troubles can be avoided using Gradle Module Metadata. Naming things is hard The dependency management troubles started early for what was previously known as the Google Collections Library. com.google.collections:google-collections:1.0 are the coordinates under which the final release of the Google Collections Library was published t