* when there is a specific reason to prioritize memory over CPU.
 *
 * @author Louis Wasserman
 */
@J2ktIncompatible // no support for access-order mode in LinkedHashMap delegate
@GwtIncompatible // not worth using in GWT for now
@ElementTypesAreNonnullByDefault
class CompactLinkedHashMap<K extends @Nullable Object, V extends @Nullable Object>
    extends CompactHashMap<K, V> {

      return build(/* throwIfDuplicateKeys= */ true);
    }

    public ImmutableMap<K, V> buildKeepingLast() {
      if (valueComparator != null) {
        // Probably not worth supporting this in GWT
        throw new UnsupportedOperationException(
            "orderEntriesByValue + buildKeepingLast not supported under GWT");
      }
      return build(/* throwIfDuplicateKeys= */ false);
    }

       * parameters. If it were statically checked, the checker would still be OK with it, since
       * we're copying into a `contents` array whose type allows it to contain nulls. Still, it's
       * worth noting that we promise not to put nulls into the array in the first `size` elements.
       * We uphold that promise here because our callers promise that `elements` will not contain
       * nulls in its first `n` elements.

    RandomAccessReverseList(List<T> forwardList) {
      super(forwardList);
    }
  }

  /** An implementation of {@link List#hashCode()}. */
  static int hashCodeImpl(List<?> list) {
    // TODO(lowasser): worth optimizing for RandomAccess?
    int hashCode = 1;
    for (Object o : list) {
      hashCode = 31 * hashCode + (o == null ? 0 : o.hashCode());

      hashCode = ~~hashCode;

  }

  /*
   * Now we have monster tests that create hundreds of Orderings using different
   * combinations of methods, then checks compare(), binarySearch() and so
   * forth on each one.
   */

  // should periodically try increasing this, but it makes the test run long
  private static final int RECURSE_DEPTH = 2;

  public void testCombinationsExhaustively_startingFromNatural() {

  }

  /*
   * Now we have monster tests that create hundreds of Orderings using different
   * combinations of methods, then checks compare(), binarySearch() and so
   * forth on each one.
   */

  // should periodically try increasing this, but it makes the test run long
  private static final int RECURSE_DEPTH = 2;

  public void testCombinationsExhaustively_startingFromNatural() {

  ZERO(0),
  /** Test a one-element collection. */
  ONE(1),
  /** Test a three-element collection. */
  SEVERAL(3),
  /*
   * TODO: add VERY_LARGE, noting that we currently assume that the fourth
   * sample element is not in any collection
   */

  ANY(ZERO, ONE, SEVERAL);

  private final Set<Feature<? super Collection>> implied;
  private final @Nullable Integer numElements;

            obvious way to ensure that.

            We could consider arranging things so that only the tests we know need this would get
            the add-opens. Right now that doesn't seem worth the effort, though.
        -->
        <test.add.opens>
          --add-opens java.base/java.lang=ALL-UNNAMED
          --add-opens java.base/java.util=ALL-UNNAMED

  ZERO(0),
  /** Test a one-element collection. */
  ONE(1),
  /** Test a three-element collection. */
  SEVERAL(3),
  /*
   * TODO: add VERY_LARGE, noting that we currently assume that the fourth
   * sample element is not in any collection
   */

  ANY(ZERO, ONE, SEVERAL);

  private final Set<Feature<? super Collection>> implied;
  private final @Nullable Integer numElements;

   *
   * @param <V1> the type returned by the first future
   * @param <V2> the type returned by the second future
   * @param <V3> the type returned by the third future
   * @param <V4> the type returned by the fourth future
   */
  public static final class Combiner4<
          V1 extends @Nullable Object,
          V2 extends @Nullable Object,
          V3 extends @Nullable Object,
          V4 extends @Nullable Object>