*
   * @since 7.0
   */
  @Override
  protected boolean standardContains(@Nullable Object object) {
    try {
      // any ClassCastExceptions and NullPointerExceptions are caught
      @SuppressWarnings({"unchecked", "nullness"})
      SortedSet<@Nullable Object> self = (SortedSet<@Nullable Object>) this;
      Object ceiling = self.tailSet(object).first();

 * way that affects its {@link Object#equals} behavior. Undefined behavior and bugs will result.
 *
 * @author Jared Levy
 * @since 2.0
 */
@GwtCompatible
public final class HashMultimap<K extends @Nullable Object, V extends @Nullable Object>
    extends AbstractSetMultimap<K, V> {
  private static final int DEFAULT_VALUES_PER_KEY = 2;

  @VisibleForTesting transient int expectedValuesPerKey = DEFAULT_VALUES_PER_KEY;

  /**

  }

  private boolean containsMapping(
      @Nullable Object rowKey, @Nullable Object columnKey, @Nullable Object value) {
    return value != null && value.equals(get(rowKey, columnKey));
  }

  /** Remove a row key / column key / value mapping, if present. */
  private boolean removeMapping(
      @Nullable Object rowKey, @Nullable Object columnKey, @Nullable Object value) {
    if (containsMapping(rowKey, columnKey, value)) {

  @Override
  public Comparator<? super E> comparator() {
    return comparator;
  }

  @Override
  public @Nullable Entry<E> firstEntry() {
    Iterator<Entry<E>> entryIterator = entryIterator();
    return entryIterator.hasNext() ? entryIterator.next() : null;
  }

  @Override
  public @Nullable Entry<E> lastEntry() {
    Iterator<Entry<E>> entryIterator = descendingEntryIterator();

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code

 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},
 *       typically because the type forbids nullable type arguments: For example, {@code