/*
     * 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

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

   * 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.

     * SynchronizedHelper is meant for Android, but our best way to test it is under the JVM.
     *
     * SynchronizedHelper also ends up getting used under the JVM during
     * AggregateFutureStateFallbackAtomicHelperTest, as discussed in a comment in
     * AggregateFutureState.
     *
     * Here, we check that we're able to force AbstractFutureState to select SynchronizedHelper, and

   * TreeBasedTable}.
   */
  public static <R, C, V> TreeBasedTable<R, C, V> create(TreeBasedTable<R, C, ? extends V> table) {
    TreeBasedTable<R, C, V> result =
        // requireNonNull is safe, as discussed in rowComparator() below.
        new TreeBasedTable<>(
            requireNonNull(table.rowKeySet().comparator()), table.columnComparator());
    result.putAll(table);
    return result;
  }

 * 1. The type parameter is <T> rather than <T extends @Nullable> so that we can use T in the
 * doForward and doBackward methods to indicate that the parameter cannot be null. (We also take
 * advantage of that for convertAll, as discussed on that method.)
 *
 * 2. The supertype of this class could be `Function<@Nullable A, @Nullable B>`, since
 * Converter.apply (like Converter.convert) is capable of accepting null inputs. However, a

* Before the PR is applied, the new tests should fail.
* After applying the PR, the new tests should pass.
* Coverage should stay at 100%.
* If you see the PR makes sense, or we discussed it and considered it should be accepted, you can add commits on top of the PR to tweak it, to add docs, tests, format, refactor, remove extra files, etc.