UseGuavaInYourBuild

Using Guava in your build

How to configure your build

For any code snippet below, please substitute the version given with the version of Guava you wish to use.

Maven

Add the following snippet to the <dependencies /> section:

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>23.5-jre</version> <!-- or 23.5-android for the Android flavor -->
</dependency>

Gradle

Ensure the maven standard repositories are available like so:

repositories {
  mavenCentral()
}

Then add the Guava dependency in the dependencies section like so:

dependencies {
  compile group: 'com.google.guava', name: 'guava', version: '23.5-jre' # or 23.5-android for the Android flavor
}

Ivy

Add the following line to the dependencies section:

<dependency org="com.google.guava" name="guava" rev="23.5-jre" /> <!-- or rev="23.5-android" for the Android flavor -->

and make sure that the "public" resolver is used.

Buildr

Include this:

compile.with 'com.google.guava:guava:jar:23.5-jre' # or '...:23.5-android' for the Android flavor

Manual Dependencies

You can also just manually download JARs for the classes, sources and javadocs. See the appropriate release.

What about GWT?

In all the examples above, leave "com.google.guava" as it is but replace the other occurrence of "guava" with "guava-gwt". (There is no GWT artifact for the Android flavor.)

What about Guava's own dependencies?

Guava has one dependency that is needed for linkage at runtime: com.google.guava:failureaccess:1.0.1. We create this as part of making ListenableFuture available as a separate artifact from the rest of Guava.

Guava also depends on some artifacts that contain only annotations. This is primarily for use by static analysis tools and certain compilers, so these annotations usually need not be present in your runtime classpath unless you want your app to recognize those annotations. (However, there may be exceptions for applications that use reflection, even if they are not looking specifically for these annotations. For example, see the discussion of NoClassDefFoundError in JDK-8247797.) In many cases, they need not be present even in your compile-time classpath. Yet we make them available in your compile-time classpath by default to avoid errors in unusual cases. (For examples, see #2652 / #2837 / auto#1032 (annotation processors -- which can also fail silently), #2721 / #2824 (-Xlint:all -Werror), and #1095 / #1127 (Scala).) If you wish to avoid the dependencies, you can usually safely exclude them.

(Users sometimes request that we make the annotations available at compile-time but not runtime. This is not currently possible in Maven's model, but it recently became possible in Gradle's model. We are considering doing this for at least the j2objc-annotations artifact (whose annotations don't have runtime retention, anyway), but we will probably not do so for the others, given the uncertain dangers of omitting the annotations even only at runtime.)

How do I avoid conflicts between multiple versions of Guava?

In the simple case, just upgrade your project to the newest version of Guava. Or, if you don't use Guava directly, use dependency management to select the newest version of Guava for all your dependencies. However, this can fail in some cases:

• One of your dependencies uses @Beta APIs against our warnings.
• One of your dependencies uses a version of Guava from the days when we were still removing non-@Beta APIs.

In these cases, you may be able to find an older version of Guava that satisfies all your dependencies. However, the only general solution is for all projects to update to at least Guava 21 and for those used as dependencies to avoid @Beta APIs.

What if I want to use @Beta APIs from a library that people use as a dependency?

First, please let us know. We may be able to remove @Beta from the APIs you need. Even if we can't do it immediately, we'd like to know about your need so that we can prioritize better.

Second, if you don't need to expose Guava types to users in your API (e.g., expose a public method that returns ImmutableList), you can configure your build to shade/relocate Guava: You write your code against Guava as usual, and your build creates a private copy of Guava, rewrites your compiled code to use it, and includes it in your artifact. All you need is some Maven configuration like that shown below. Just substitute in a package of your own for my.organization in the shadedPattern:

      <plugin>
        <artifactId>maven-shade-plugin</artifactId>
        <version>3.1.0</version>
        <configuration>
          <artifactSet>
            <includes>
              <include>com.google.guava:*</include>
            </includes>
          </artifactSet>
          <relocations>
            <relocation>
              <pattern>com.google</pattern>
              <shadedPattern>my.organization.repackaged.com.google</shadedPattern>
            </relocation>
          </relocations>
        </configuration>
        <executions>
          <execution>
            <phase>package</phase>
            <goals>
              <goal>shade</goal>
            </goals>
          </execution>
        </executions>
      </plugin>

Gradle users can do the same with the Shadow Plugin.