*       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

      List<@Nullable String> listWithNulls = asList("a", null, "b");
      assertThrows(NullPointerException.class, () -> builder.addAll((List<String>) listWithNulls));
    }

    {
      ImmutableMultiset.Builder<String> builder = ImmutableMultiset.builder();
      Multiset<@Nullable String> multisetWithNull =
          LinkedHashMultiset.create(Arrays.<@Nullable String>asList("a", null, "b"));

              }

              @Override
              public boolean equals(@Nullable Object o) {
                return map.equals(o);
              }

              @Override
              public String toString() {
                return map.toString();
              }

              @Override
              public @Nullable String remove(Object key) {
                return map.remove(key);
              }

import org.jspecify.annotations.Nullable;

/**
 * Tests for {@link AbstractFuture} that use a non-{@link TrustedFuture} for {@link
 * AbstractFuture#setFuture} calls.
 */
@GwtCompatible
@NullUnmarked
public class UntrustedInputFutureTest extends AbstractAbstractFutureTest {
  @Override
  AbstractFuture<@Nullable Integer> newDelegate() {

  @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();

    }
  }

  @Override
  public @Nullable Entry<E> firstEntry() {
    return delegate().firstEntry();
  }

  /**
   * A sensible definition of {@link #firstEntry()} in terms of {@code entrySet().iterator()}.
   *
   * <p>If you override {@link #entrySet()}, you may wish to override {@link #firstEntry()} to
   * forward to this implementation.
   */
  protected @Nullable Entry<E> standardFirstEntry() {

   *
   * 2. `other[size] = null` is unsound. We could "fix" this by requiring callers to pass in an
   * array with a nullable element type. But probably they usually want an array with a non-nullable
   * type. That said, we could *accept* a `@Nullable T[]` (which, given that we treat arrays as
   * covariant, would still permit a plain `T[]`) and return a plain `T[]`. But of course that would