}
      };
    }

    /**
     * Uses a {@link LinkedList} to store value collections.
     *
     * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently
     * outperform {@code LinkedList} except in certain rare and specific situations. Unless you have
     * spent a lot of time benchmarking your specific needs, use one of those instead. (However, we

        }
      };
    }

    /**
     * Uses a {@link LinkedList} to store value collections.
     *
     * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently
     * outperform {@code LinkedList} except in certain rare and specific situations. Unless you have
     * spent a lot of time benchmarking your specific needs, use one of those instead. (However, we

   * example, {@code [] < [1] < [1, 2] < [2]}.
   *
   * <p>The returned comparator is inconsistent with {@link Object#equals(Object)} (since arrays
   * support only identity equality), but it is consistent with {@link Arrays#equals(int[], int[])}.
   *
   * @since 2.0
   */
  public static Comparator<int[]> lexicographicalComparator() {
    return LexicographicalComparator.INSTANCE;
  }

 * multimap.put(key1, baz);
 * }
 *
 * ... the iteration order for {@link #keys()} is {@code [key1, key2, key1]}, and similarly for
 * {@link #entries()}. Unlike {@link LinkedHashMultimap}, the iteration order is kept consistent
 * between keys, entries and values. For example, calling:
 *
 * {@snippet :
 * multimap.remove(key1, foo);
 * }
 *
 * <p>changes the entries iteration order to {@code [key2=bar, key1=baz]} and the key iteration

    assertEquals(1, IntMath.saturatedAbs(-1));
    assertEquals(10, IntMath.saturatedAbs(10));
    assertEquals(10, IntMath.saturatedAbs(-10));
  }

  private static int force32(int value) {
    // GWT doesn't consistently overflow values to make them 32-bit, so we need to force it.
    return value & 0xffffffff;
  }

   *   is reserved to mean "uninitialized". If timeout is non-positive, then nanoTime need never be
   *   called.
   * - Keep behavior of fair and non-fair instances consistent.
   */

  /**
   * A boolean condition for which a thread may wait. A {@code Guard} is associated with a single
   * {@code Monitor}. The monitor may check the guard at arbitrary times from any thread occupying

    return new ColumnKeyIterator();
  }

  private final class ColumnKeyIterator extends AbstractIterator<C> {
    // Use the same map type to support TreeMaps with comparators that aren't
    // consistent with equals().
    final Map<C, V> seen = factory.get();
    final Iterator<Map<C, V>> mapIterator = backingMap.values().iterator();
    Iterator<Entry<C, V>> entryIterator = emptyIterator();

    @Override

     * However, serialization does not preserve that property, though it does maintain the key and
     * value ordering.
     *
     * @since 8.0
     */
    // TODO: Make serialization behavior consistent.
    @CanIgnoreReturnValue
    @Override
    public Builder<K, V> orderValuesBy(Comparator<? super V> valueComparator) {
      super.orderValuesBy(valueComparator);
      return this;
    }

      Class<X> exceptionType, ClosingFunction<? super X, ? extends V> fallback, Executor executor) {
    return catchingMoreGeneric(exceptionType, fallback, executor);
  }

  // Avoids generic type capture inconsistency problems where |? extends V| is incompatible with V.
  private <X extends Throwable, W extends V> ClosingFuture<V> catchingMoreGeneric(
      Class<X> exceptionType, ClosingFunction<? super X, W> fallback, Executor executor) {

  companion object {
    /**
     * Compares cipher suites names like "TLS_RSA_WITH_NULL_MD5" and "SSL_RSA_WITH_NULL_MD5",
     * ignoring the "TLS_" or "SSL_" prefix which is not consistent across platforms. In particular
     * some IBM JVMs use the "SSL_" prefix everywhere whereas Oracle JVMs mix "TLS_" and "SSL_".
     */
    internal val ORDER_BY_NAME =
      object : Comparator<String> {