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

    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.

    /*
     * 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();

   * would declare a return type of `@Nullable T[]`. However, we've decided not to think too hard
   * about arrays for now, as they're a mess. (We previously discussed this in the review of
   * ObjectArrays, which is the main caller of this method.)
   */
  static <T extends @Nullable Object> T[] newArray(T[] reference, int length) {

   * would declare a return type of `@Nullable T[]`. However, we've decided not to think too hard
   * about arrays for now, as they're a mess. (We previously discussed this in the review of
   * ObjectArrays, which is the main caller of this method.)
   */
  static <T extends @Nullable Object> T[] newArray(T[] reference, int length) {