*       how the collection was created. Typically this is insertion order unless an explicit
 *       ordering is otherwise specified (e.g. {@link ImmutableSortedSet#naturalOrder}). See the
 *       appropriate factory method for details. View collections such as {@link
 *       ImmutableMultiset#elementSet} iterate in the same order as the parent, except as noted.

 * the keys in the order they were first added to the multimap. Similarly, {@code get}, {@code
 * removeAll}, and {@code replaceValues} return collections that iterate through the values in the
 * order they were added. The collections generated by {@code entries} and {@code values} iterate
 * across the key-value mappings in the order they were added to the multimap.
 *

		t.Fatalf("Build Order condition, but got %v", result.Statement.SQL.String())
	}

	result = dryDB.Order("age desc, name").Find(&User{})
	if !regexp.MustCompile("SELECT \\* FROM .*users.* ORDER BY age desc, name").MatchString(result.Statement.SQL.String()) {
		t.Fatalf("Build Order condition, but got %v", result.Statement.SQL.String())
	}

	result = dryDB.Order("age desc").Order("name").Find(&User{})

   */
  E[] createArray(int length);

  /**
   * Returns the iteration ordering of elements, given the order in which they were added to the
   * container. This method may return the original list unchanged, the original list modified in
   * place, or a different list.
   *
   * <p>If the order is non-deterministic, as with {@link java.util.HashSet}, this method can return

    @Override
    public Entry<K, V>[] createArray(int length) {
      return (Entry<K, V>[]) new Entry<?, ?>[length];
    }

    @Override
    public Iterable<Entry<K, V>> order(List<Entry<K, V>> insertionOrder) {
      return multimapGenerator.order(insertionOrder);
    }
  }

  private static final class ValuesGenerator<K, V, M extends Multimap<K, V>>
      implements TestCollectionGenerator<V> {

  /*
   * While the current implementation returns `this`, that's not something we mean to guarantee.
   * Callers of TestContainerGenerator.order need to be prepared for implementations to return a new
   * collection.
   */
  @SuppressWarnings("CanIgnoreReturnValueSuggester")
  @Override
  public List<String> order(List<String> insertionOrder) {
    sort(insertionOrder);
    return insertionOrder;
  }

  @Override

    // it.
    executeListener(runnable, executor);
  }

  /**
   * Runs this execution list, executing all existing pairs in the order they were added. However,
   * note that listeners added after this point may be executed before those previously added, and
   * note that the execution order of all listeners is ultimately chosen by the implementations of
   * the supplied executors.
   *

 *
 * <p>A {@code ValueGraph} built by this class has the following default properties:
 *
 * <ul>
 *   <li>does not allow self-loops
 *   <li>orders {@link ValueGraph#nodes()} in the order in which the elements were added (insertion
 *       order)
 * </ul>
 *
 * <p>{@code ValueGraph}s built by this class also guarantee that each collection-returning accessor
 * returns a <b>(live) unmodifiable view</b>; see <a

 *
 * <p><b>Key-grouped iteration.</b> All view collections follow the same iteration order. In all
 * current implementations, the iteration order always keeps multiple entries with the same key
 * together. Any creation method that would customarily respect insertion order (such as {@link
 * #copyOf(Multimap)}) instead preserves key-grouped order by inserting entries for an existing key
 * immediately after the last entry having that key.
 *

	}

	// Tests hashing order to be consistent.
	for i, testCase := range testCases {
		hashedOrder := hashOrder(testCase.objectName, 16)
		if !reflect.DeepEqual(testCase.hashedOrder, hashedOrder) {
			t.Errorf("Test case %d: Expected \"%v\" but failed \"%v\"", i+1, testCase.hashedOrder, hashedOrder)
		}
	}

	// Tests hashing order to fail for when order is '-1'.