abstract class AbstractAbstractFutureTest extends TestCase {
  @SuppressWarnings("initialization.field.uninitialized")
  private TestedFuture<@Nullable Integer> future;

  @SuppressWarnings("initialization.field.uninitialized")
  private AbstractFuture<@Nullable Integer> delegate;

  abstract AbstractFuture<@Nullable Integer> newDelegate();

  @Override
  protected void setUp() {
    future = TestedFuture.create();
    delegate = newDelegate();
  }

    LAST_BEFORE {
      @Override
      public <E extends @Nullable Object> int resultIndex(
          Comparator<? super E> comparator,
          @ParametricNullness E key,
          List<? extends E> list,
          int foundIndex) {
        return FIRST_PRESENT.resultIndex(comparator, key, list, foundIndex) - 1;
      }
    };

    abstract <E extends @Nullable Object> int resultIndex(
        Comparator<? super E> comparator,

import java.util.Map.Entry;
import java.util.Set;
import org.jspecify.annotations.Nullable;

/**
 * Implementation of {@link Multimaps#filterEntries(SetMultimap, Predicate)}.
 *
 * @author Louis Wasserman
 */
@GwtCompatible
final class FilteredEntrySetMultimap<K extends @Nullable Object, V extends @Nullable Object>
    extends FilteredEntryMultimap<K, V> implements FilteredSetMultimap<K, V> {

 *       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

  @Override
  public <T extends @NonNull B> @Nullable T getInstance(Class<T> type) {
    return trustedGet(TypeToken.of(type));
  }

  @Override
  public <T extends @NonNull B> @Nullable T getInstance(TypeToken<T> type) {
    return trustedGet(type.rejectTypeVariables());
  }

  @Override
  @CanIgnoreReturnValue
  public <T extends B> @Nullable T putInstance(

  @Override
  ContiguousSet<C> tailSetImpl(C fromElement, boolean fromInclusive) {
    return this;
  }

  @Override
  public boolean contains(@Nullable Object object) {
    return false;
  }

  @GwtIncompatible // not used by GWT emulation
  @Override
  int indexOf(@Nullable Object target) {
    return -1;
  }

  @Override
  public UnmodifiableIterator<C> iterator() {
    return emptyIterator();
  }