abstract <R> @Nullable R dummyReturnValue(TypeToken<R> returnType);

  private final class DummyHandler extends AbstractInvocationHandler implements Serializable {
    private final TypeToken<?> interfaceType;

    DummyHandler(TypeToken<?> interfaceType) {
      this.interfaceType = interfaceType;
    }

    @Override
    protected @Nullable Object handleInvocation(

import org.jspecify.annotations.Nullable;

/**
 * Tests for {@link AbstractFuture} that use a {@link TrustedFuture} for {@link
 * AbstractFuture#setFuture} calls.
 */
@GwtCompatible
@NullUnmarked
public class TrustedInputFutureTest extends AbstractAbstractFutureTest {
  @Override
  AbstractFuture<@Nullable Integer> newDelegate() {
    AbstractFuture<@Nullable Integer> future = new TrustedFuture<@Nullable Integer>() {};

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() {

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

 * @author Ben Yu
 * @since 12.0
 */
/*
 * A nullable bound would let users create a TypeParameter instance for a parameter with a nullable
 * bound. However, it would also let them create `new TypeParameter<@Nullable T>() {}`, which
 * wouldn't behave as users might expect. Additionally, it's not clear how the TypeToken API could
 * support even a "normal" `TypeParameter<T>` when `<T>` has a nullable bound. (See the discussion

 *       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

            DefaultDependencyResolverRequest(
                    @Nonnull Session session,
                    @Nullable RequestTrace trace,
                    @Nonnull RequestType requestType,
                    @Nullable Project project,
                    @Nullable Artifact rootArtifact,
                    @Nullable DependencyCoordinates root,
                    @Nonnull Collection<DependencyCoordinates> dependencies,

import java.util.List;
import org.jspecify.annotations.Nullable;

/**
 * GWT emulated version of {@link ImmutableList}. TODO(cpovirk): more doc
 *
 * @author Hayward Chan
 */
abstract class ForwardingImmutableList<E> extends ImmutableList<E> {

  ForwardingImmutableList() {}

  abstract List<E> delegateList();

  @Override
  public int indexOf(@Nullable Object object) {
    return delegateList().indexOf(object);

    public static Object good(
        String a,
        int b,
        // oneConstantOnly doesn't matter since it's not nullable and can be only 1 value.
        @SuppressWarnings("unused") OneConstantEnum oneConstantOnly,
        // noConstant doesn't matter since it can only be null
        @SuppressWarnings("unused") @Nullable NoConstantEnum noConstant) {
      return new GoodEquals(a, b);
    }

    // instance method ignored