// Test implementation of ThumbnailManager to avoid container dependencies
    private class TestThumbnailManager extends ThumbnailManager {
        @Override
        public void init() {
            // Do nothing to avoid container access
        }

        @Override
        protected void storeQueue(List<Tuple3<String, String, String>> taskList) {
            // Override to avoid database operations
            taskList.clear();

            "requires": "1.0.3"
          }
        },
        {
          "group": "com.google.guava",
          "module": "listenablefuture",
          "version": {
            "requires": "9999.0-empty-to-avoid-conflict-with-guava"
          }
        },
        {
          "group": "org.jspecify",
          "module": "jspecify",
          "version": {
            "requires": "${jspecify.version}"
          }

 * family. <b>Avoid</b> creating a mock or stub {@code Future}. Mock and stub implementations are
 * fragile because they assume that only certain methods will be called and because they often
 * implement subtleties of the API improperly.
 *
 * <p><b>Custom implementation</b>: Avoid implementing {@code ListenableFuture} from scratch. If you

    return when {
      type == TYPE_PUSH_PROMISE && flags and FLAG_END_PUSH_PROMISE != 0 -> {
        result.replace("HEADERS", "PUSH_PROMISE") // TODO: Avoid allocation.
      }
      type == TYPE_DATA && flags and FLAG_COMPRESSED != 0 -> {
        result.replace("PRIORITY", "COMPRESSED") // TODO: Avoid allocation.
      }
      else -> result
    }
  }

        .testEquals();
  }

  /*
   * We use large numbers to avoid the integer cache. Normally, we'd accomplish that merely by using
   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple

        .testEquals();
  }

  /*
   * We use large numbers to avoid the integer cache. Normally, we'd accomplish that merely by using
   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple

   * in a {@code RuntimeException}. <b>Note:</b> Be sure to declare all of the checked exception
   * types your try block can throw when calling an overload of this method so as to avoid losing
   * the original exception type.
   *
   * <p>This method always throws, and as such should be called as {@code throw closer.rethrow(e);}
   * to ensure the compiler knows that it will throw.
   *

 * family. <b>Avoid</b> creating a mock or stub {@code Future}. Mock and stub implementations are
 * fragile because they assume that only certain methods will be called and because they often
 * implement subtleties of the API improperly.
 *
 * <p><b>Custom implementation</b>: Avoid implementing {@code ListenableFuture} from scratch. If you

 * family. <b>Avoid</b> creating a mock or stub {@code Future}. Mock and stub implementations are
 * fragile because they assume that only certain methods will be called and because they often
 * implement subtleties of the API improperly.
 *
 * <p><b>Custom implementation</b>: Avoid implementing {@code ListenableFuture} from scratch. If you

  static final Iterable<Integer> ALL_INTEGER_CANDIDATES;

  static {
    ImmutableSet.Builder<Integer> intValues = ImmutableSet.builder();
    // Add boundary values manually to avoid over/under flow (this covers 2^N for 0 and 31).
    intValues.add(Integer.MAX_VALUE - 1, Integer.MAX_VALUE);
    // Add values up to 40. This covers cases like "square of a prime" and such.
    for (int i = 1; i <= 40; i++) {