@GwtCompatible
@Ignore // Affects only Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
public class AbstractSetTester<E> extends AbstractCollectionTester<E> {
  /*
   * Previously we had a field named set that was initialized to the value of
   * collection in setUp(), but that caused problems when a tester changed the
   * value of set or collection but not both.
   */
  protected final Set<E> getSet() {

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

<module>
<source path="">
  <!-- Hack to keep collect from hiding collect.testing supersource: -->
  <exclude name="**/testing/**"/>
</source>

<!--
    We used to set this only for packages that had manual supersource. That
    worked everywhere that I know of except for one place: when running the GWT
    util.concurrent tests under Guava.

    The problem is that GWT responds poorly to two .gwt.xml files in the same

    bulkFuture.addListener(
        new Runnable() {
          @Override
          public void run() {
            /*
             * firstFuture just completed, but AggregateFuture hasn't yet had time to record the
             * exception in seenExceptions. When we complete secondFuture with the same exception,
             * we want for AggregateFuture to still detect that it's been previously seen.
             */

 *
 * <p>The maps produced by {@code MapMaker} are serializable, and the deserialized maps retain all
 * the configuration properties of the original map. During deserialization, if the original map had
 * used weak references, the entries are reconstructed as they were, but it's not unlikely they'll
 * be quickly garbage-collected before they are ever accessed.
 *

 * Tasks execute with the same happens-before order that the function calls to {@link #submit} and
 * {@link #submitAsync} that submitted those tasks had.
 *
 * <p>This class has limited support for cancellation and other "early completions":
 *
 * <ul>
 *   <li>While calls to {@code submit} and {@code submitAsync} return a {@code Future} that can be

     * so that we can pass non-null instances of the interface.
     *
     * (Currently it's safe to pass instances for which compareTo() always
     * returns 0, but if we had a SingletonImmutableSortedSet, this might no
     * longer be the case.)
     *
     * javax.naming.Name and java.util.concurrent.Delayed might work, but

   *
   * However, for a variety of reasons, Google developers have written a ton of code over the past
   * decade that assumes that they can use checkNotNull for non-precondition checks. I had hoped to
   * take a principled stand on this, but the amount of such code is simply overwhelming. To avoid
   * creating a lot of compile errors that users would not find to be informative, we're giving in