// otherwise try to presize a StringBuilder
          // it is kind of lame that we need to construct a decoder to access this value.
          // if this is a concern we could add special cases for some known charsets (like utf8)
          // or we could avoid inputstreamreader and use the decoder api directly
          // TODO(lukes): in a real implementation we would need to handle overflow conditions

          <!-- We add the link ourselves, both so that we can choose Java 9 over the version that -source suggests and so that we can solve the JSR305 problem described below. -->
          <detectJavaApiLink>false</detectJavaApiLink>
          <offlineLinks>

    return new SingletonImmutableSet<>(e1);
  }

  /*
   * TODO: b/315526394 - Skip the Builder entirely for the of(...) methods, since we don't need to
   * worry that we might trigger the fallback to the JDK-backed implementation? (The varargs one
   * _could_, so we could keep it as it is. Or we could convince ourselves that hash flooding is
   * unlikely in practice there, too.)
   */

  /**

  /*
   * J2CL's EnumMap does not need the Class instance, so we can use Object.class instead. (Or we
   * could use null, but that messes with our nullness checking, including under J2KT. We could
   * probably work around it by changing how we annotate the J2CL EnumMap, but that's probably more
   * trouble than just using Object.class.)
   *
   * Then we declare the getters for these fields as @GwtIncompatible so that no one can try to use

  /*
   * J2CL's EnumMap does not need the Class instance, so we can use Object.class instead. (Or we
   * could use null, but that messes with our nullness checking, including under J2KT. We could
   * probably work around it by changing how we annotate the J2CL EnumMap, but that's probably more
   * trouble than just using Object.class.)
   *
   * Then we declare the getters for these fields as @GwtIncompatible so that no one can try to use

     * StackOverflowError: We can't reliably call setException(error).
     *
     * - Any kind of Error from a listener. Even if we could distinguish that case (by exposing some
     * extra state from AbstractFuture), our options are limited: A call to setException() would be
     * a no-op. We could log, but if that's what we really want, we should modify

  private final ImmutableMap<C, ImmutableMap<R, V>> columnMap;

  @SuppressWarnings("Immutable") // We don't modify this after construction.
  private final int[] rowCounts;

  @SuppressWarnings("Immutable") // We don't modify this after construction.
  private final int[] columnCounts;

  @SuppressWarnings("Immutable") // We don't modify this after construction.
  private final @Nullable V[][] values;

      } finally {
        monitor.leave();
      }
    } else {
      // It is possible due to races that we are currently in the expected state even though we
      // timed out. e.g. if we weren't event able to grab the lock within the timeout we would never
      // even check the guard. I don't think we care too much about this use case but it could lead
      // to a confusing error message.

   * objects per entry.  Instead we use an open-addressed hash table.  This design is basically
   * equivalent to RegularImmutableSet, save that instead of having a hash table containing the
   * elements directly and null for empty positions, we store indices of the keys in the hash table,
   * and ABSENT for empty positions.  We then look up the keys in alternatingKeysAndValues.
   *

 * nullness annotations in particular will outweigh the costs. (And it's worth noting that we have
 * released multiple ListenableFuture.class files that are not byte-for-byte compatible even from
 * the beginning, thanks to using different `-source -target` values for compiling our `-jre` and
 * `-android` "flavors.")
 *