flavor.

-   Snapshot API Docs: [guava][guava-snapshot-api-docs]
-   Snapshot API Diffs: [guava][guava-snapshot-api-diffs]

## Learn about Guava

-   Our users' guide, [Guava Explained]
-   [A nice collection](https://www.tfnico.com/presentations/google-guava) of
    other helpful links

## Links

-   [GitHub project](https://github.com/google/guava)

    executor.execute(task);
    assertEquals(1, numCalls.get());
  }

  /*
   * Under Android, MyError propagates up and fails the test?
   *
   * TODO(b/218700094): Does this matter to prod users, or is it just a feature of our testing
   * environment? If the latter, maybe write a custom Executor that avoids failing the test when it
   * sees an Error?
   */
  @AndroidIncompatible

     * didn't see that discussed in the review, which included many other
     * changes: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make
     * entrySet().add() tests tolerant of either behavior, introduce a map
     * feature for entrySet() that supports add(), or something else
     */

 * that is already in the desired state.
 *
 * <p>When testing code that uses this class, use {@link #createUnstarted(Ticker)} or {@link
 * #createStarted(Ticker)} to supply a fake or mock ticker. This allows you to simulate any valid
 * behavior of the stopwatch.
 *
 * <p><b>Note:</b> This class is not thread-safe.
 *
 * <p><b>Warning for Android users:</b> a stopwatch with default behavior may not continue to keep

  }

  @SuppressWarnings("unused") // compilation test
  public void testSampleCodeFine2() {
    FluentIterable<? extends Number> numbers = getSomeNumbers();

    // Sadly, the following is what users will have to do in some circumstances.

    @SuppressWarnings("unchecked") // safe covariant cast
    Optional<Number> first = (Optional<Number>) numbers.first();
    Number value = first.or(0.5); // fine
  }

        Be aware, though: most feature requests are not accepted, even if they're suggested by
        a full-time Guava team member. [Feedback](https://stackoverflow.com/a/4543114) from our
        users indicates that they really appreciate Guava's high power-to-weight ratio. It's
        important to us to keep Guava as easy to use and understand as we can. That means boiling

     * didn't see that discussed in the review, which included many other
     * changes: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make
     * entrySet().add() tests tolerant of either behavior, introduce a map
     * feature for entrySet() that supports add(), or something else
     */

        // getDeclaredField to throw a NoSuchFieldException when the field is definitely there.
        // For these users fallback to a suboptimal implementation, based on synchronized. This will
        // be a definite performance hit to those users.
        thrownAtomicReferenceFieldUpdaterFailure = atomicReferenceFieldUpdaterFailure;
        helper = new SynchronizedHelper();
      }
    }

   * throws an {@code IllegalStateException}.)
   *
   * @since 33.2.0 (available since 21.0 in guava-jre)
   */
  @SuppressWarnings({"AndroidJdkLibsChecker", "Java7ApiChecker"})
  @IgnoreJRERequirement // Users will use this only if they're already using streams.
  @Beta // TODO: b/288085449 - Remove.
  public static <T extends @Nullable Object, K, V>
      Collector<T, ?, ImmutableMap<K, V>> toImmutableMap(

  <name>Guava InternalFutureFailureAccess and InternalFutures</name>
  <description>
    Contains
    com.google.common.util.concurrent.internal.InternalFutureFailureAccess and
    InternalFutures. Most users will never need to use this artifact. Its
    classes are conceptually a part of Guava, but they're in this separate
    artifact so that Android libraries can use them without pulling in all of