iterator.next();
      fail("Expected ConcurrentModificationException");
    } catch (ConcurrentModificationException expected) {
      // success
    }
  }

  /** Trigger the {@code other.size() >= this.size()} case in {@link AbstractSet#removeAll}. */
  @CollectionFeature.Require(SUPPORTS_REMOVE)
  @CollectionSize.Require(absent = ZERO)

 * superclasses, and all interfaces implemented by superclasses.
 *
 * <p>When {@code post} is called, all registered subscribers for an event are run in sequence, so
 * subscribers should be reasonably quick. If an event may trigger an extended process (such as a
 * database load), spawn a thread or queue it for later. (For a convenient way to do this, use an
 * {@link AsyncEventBus}.)
 *
 * <h2>Subscriber Methods</h2>
 *

   * On the other hand, past underutilization could mean that "the server responsible for handling
   * the request has become less ready for future requests", i.e. its caches become stale, and
   * requests become more likely to trigger expensive operations (a more extreme case of this
   * example is when a server has just booted, and it is mostly busy with getting itself up to
   * speed).
   *

    awaitTimedWaiting(waiter);
    service.shutdown();
    Uninterruptibles.joinUninterruptibly(waiter, 10, TimeUnit.SECONDS);
    if (waiter.isAlive()) {
      waiter.interrupt();
      fail("awaitTermination failed to trigger after shutdown()");
    }
  }

  /** Wait for the given thread to reach the {@link State#TIMED_WAITING} thread state. */
  void awaitTimedWaiting(Thread thread) {
    while (true) {

    /*
     * TODO: cpovirk - Pre-size the HashMap based on the number of enum values? (But *not* based on
     * the number of entries in the map, as that makes it easy for hostile inputs to trigger lots of
     * allocation—not that any program should be deserializing hostile inputs to begin with!)
     */
    setDelegates(new EnumMap<K, V>(keyTypeOrObjectUnderJ2cl), new HashMap<V, K>());

   *
   * <p>Currently, this method is invoked while holding a lock. If an implementation of this method
   * blocks, it can prevent this service from changing state. If you need to performing a blocking
   * operation in order to trigger shutdown, consider instead registering a listener and
   * implementing {@code stopping}. Note, however, that {@code stopping} does not run at exactly the
   * same times as {@code triggerShutdown}.
   */

  }

  private static Set<Feature<?>> computeKeySetFeatures(Set<Feature<?>> mapFeatures) {
    Set<Feature<?>> keySetFeatures = computeCommonDerivedCollectionFeatures(mapFeatures);

    // TODO(lowasser): make this trigger only if the map is a submap
    // currently, the KeySetGenerator won't work properly for a subset of a keyset of a submap
    keySetFeatures.add(CollectionFeature.SUBSET_VIEW);

   *       to do something different. In other cases, no code will catch the exception, and it may
   *       terminate whichever thread happens to trigger the execution.
   * </ul>
   *
   * A specific warning about locking: Code that executes user-supplied tasks, such as {@code
   * ListenableFuture} listeners, should take care not to do so while holding a lock. Additionally,

    return new SingletonImmutableSet<>(e1);
  }

  /*
   * TODO: b/315526394 - Skip the Builder entirely for the of(...) methods, since we don't need to
   * worry that we might trigger the fallback to the JDK-backed implementation? (The varargs one
   * _could_, so we could keep it as it is. Or we could convince ourselves that hash flooding is
   * unlikely in practice there, too.)
   */

  /**

 * good job of distributing the elements to the buckets to a distribution not far from uniform), and
 * amortized since some operations can trigger a hash table resize.
 *
 * <p>This implementation consumes significantly less memory than {@code java.util.LinkedHashSet} or
 * even {@code java.util.HashSet}, and places considerably less load on the garbage collector. Like