* To force selection of our fallback strategies we load {@link AggregateFutureState} (and all of
 * {@code com.google.common.util.concurrent}) in degenerate class loaders which make certain
 * platform classes unavailable. Then we construct a test suite so we can run the normal FuturesTest
 * test methods in these degenerate classloaders.
 */

public class AggregateFutureStateFallbackAtomicHelperTest extends TestCase {

  /**

        emptyInstanceGenerated.put(type.getType(), freshness.get());
        return emptyInstance;
      }
    }
    Method generate = GENERATORS.get(rawType);
    if (generate != null) {
      ImmutableList<Parameter> params = Invokable.from(generate).getParameters();
      List<Object> args = Lists.newArrayListWithCapacity(params.size());
      TypeVariable<?>[] typeVars = rawType.getTypeParameters();

        env:
          CI_DEPLOY_USERNAME: ${{ secrets.CI_DEPLOY_USERNAME }}
          CI_DEPLOY_PASSWORD: ${{ secrets.CI_DEPLOY_PASSWORD }}
        run: ./util/deploy_snapshot.sh

  generate_docs:
    permissions:
      contents: write
    name: 'Generate latest docs'
    needs: test
    if: github.event_name == 'push' && github.repository == 'google/guava'
    runs-on: ubuntu-latest
    steps:
      - name: 'Check out repository'

 * <p>{@code GwtTestSuiteGenerator} expects every {@code DerivedIterator} implementation to provide
 * a one-arg constructor accepting its inner generator as an argument. This requirement enables it
 * to generate source code (since GWT cannot use reflection to generate the suites).
 *
 * @author Chris Povirk
 */
@GwtCompatible
public interface DerivedGenerator {
  TestSubjectGenerator<?> getInnerGenerator();

    // cause system property.  This allows us to run with both settings of the property in one jvm
    // without resorting to even crazier hacks to reset static final boolean fields.
    System.setProperty("guava.concurrent.generate_cancellation_cause", "true");
    final String concurrentPackage = SettableFuture.class.getPackage().getName();
    classReloader =
        new URLClassLoader(ClassPathUtil.getClassPathUrls()) {

    }
  }

  static final class ImmediateCancelledFuture<V extends @Nullable Object> extends TrustedFuture<V> {
    @CheckForNull
    static final ImmediateCancelledFuture<Object> INSTANCE =
        AbstractFuture.GENERATE_CANCELLATION_CAUSES ? null : new ImmediateCancelledFuture<>();

    ImmediateCancelledFuture() {
      cancel(false);
    }
  }

        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.7</version>
        <executions>
          <execution>
            <id>add-benchmark-sources</id>
            <phase>generate-test-sources</phase>
            <goals><goal>add-test-source</goal></goals>
            <configuration>
              <sources>
                <source>benchmark</source>
              </sources>

 * resulting {@link HashCode} is dependent only on the bytes inserted, and the order in which they
 * were inserted, not how those bytes were chunked into discrete put() operations. For example, the
 * following three expressions all generate colliding hash codes:
 *
 * <pre>{@code
 * newHasher().putByte(b1).putByte(b2).putByte(b3).hash()
 * newHasher().putByte(b1).putBytes(new byte[] { b2, b3 }).hash()
 * newHasher().putBytes(new byte[] { b1, b2, b3 }).hash()

            .createTestSuite());

    suite.addTest(
        SetTestSuiteBuilder.using(new DegeneratedImmutableSetGenerator())
            .named(ImmutableSetTest.class.getName() + ", degenerate")
            .withFeatures(
                CollectionSize.ONE,
                CollectionFeature.KNOWN_ORDER,
                CollectionFeature.ALLOWS_NULL_QUERIES)
            .createTestSuite());

    }
  }

  public void testCartesianProduct_hashCode() {
    // Run through the same cartesian products we tested above

    Set<List<Integer>> degenerate = Sets.cartesianProduct();
    checkHashCode(degenerate);

    checkHashCode(Sets.cartesianProduct(set(1, 2)));

    int num = Integer.MAX_VALUE / 3 * 2; // tickle overflow-related problems