tester.testConstructors(PatternFilenameFilter.class, Visibility.PACKAGE);
    tester.testStaticMethods(PatternFilenameFilter.class, Visibility.PACKAGE); // currently none

    // The reason that we skip this method is discussed in a comment on the method.
    tester.ignore(PatternFilenameFilter.class.getMethod("accept", File.class, String.class));
    tester.testInstanceMethods(new PatternFilenameFilter(".*"), Visibility.PACKAGE);
  }

    /*
     * The entrySet() of ConcurrentHashMap, unlike that of other Map
     * implementations, supports add() under JDK8. This seems problematic, but I
     * didn't see that discussed in the review, which included many other
     * changes: https://mail.openjdk.org/pipermail/core-libs-dev/2013-May/thread.html#17367
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users

    tester.testConstructors(PatternFilenameFilter.class, Visibility.PACKAGE);
    tester.testStaticMethods(PatternFilenameFilter.class, Visibility.PACKAGE); // currently none

    // The reason that we skip this method is discussed in a comment on the method.
    tester.ignore(PatternFilenameFilter.class.getMethod("accept", File.class, String.class));
    tester.testInstanceMethods(new PatternFilenameFilter(".*"), Visibility.PACKAGE);
  }

    /*
     * The entrySet() of ConcurrentHashMap, unlike that of other Map
     * implementations, supports add() under JDK8. This seems problematic, but I
     * didn't see that discussed in the review, which included many other
     * changes: https://mail.openjdk.org/pipermail/core-libs-dev/2013-May/thread.html#17367
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users

   * flavors can read old data or data from the other flavor. However, we strongly discourage
   * relying on this, as we have made incompatible changes to serialized forms in the past and
   * expect to do so again, as discussed in https://github.com/google/guava#important-warnings.
   */
  @SuppressWarnings("unused")
  private static final class SerializedForm<V> implements Serializable {
    final ImmutableMap<?, V> map;

   *   holdsLock assertions.
   *
   * - For stream() and spliterator(), we have to forward to the delegate ourselves because
   *   ForwardingSet does not forward `default` methods, as discussed in its Javadoc.
   */

  // Currently, we don't include stream() and spliterator() for our classes in the Android flavor.

  @Override
  public boolean remove(@Nullable Object o) {

   *   holdsLock assertions.
   *
   * - For stream() and spliterator(), we have to forward to the delegate ourselves because
   *   ForwardingSet does not forward `default` methods, as discussed in its Javadoc.
   */

  @Override
  public Stream<E> stream() {
    return delegate.stream();
  }

  @Override
  public Spliterator<E> spliterator() {
    return delegate.spliterator();

   * flavors can read old data or data from the other flavor. However, we strongly discourage
   * relying on this, as we have made incompatible changes to serialized forms in the past and
   * expect to do so again, as discussed in https://github.com/google/guava#important-warnings.
   */
  @SuppressWarnings("unused")
  private static final class SerializedForm<V> implements Serializable {
    final ImmutableMap<?, V> map;

    extends AggregateFuture<V, C> {
  /*
   * We access this field racily but safely. For discussion of a similar situation, see the comments
   * on the fields of TimeoutFuture. This field is slightly different from the fields discussed
   * there: cancel() never reads this field, only writes to it. That makes the race here completely
   * harmless, rather than just 99.99% harmless.
   */
  @LazyInit private @Nullable List<@Nullable Present<V>> values;

start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.