*   <li>{@link Multimaps}
 *   <li>{@link Multisets}
 *   <li>{@link ObjectArrays}
 *   <li>{@link Queues}
 *   <li>{@link Sets}
 *   <li>{@link Streams}
 *   <li>{@link Tables}
 * </ul>
 *
 * <h2>Abstract implementations</h2>
 *
 * <ul>
 *   <li>{@link AbstractIterator}
 *   <li>{@link AbstractSequentialIterator}
 *   <li>{@link UnmodifiableIterator}
 *   <li>{@link UnmodifiableListIterator}
 * </ul>

 *
 * <ul>
 *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
 *       suppression. This would follow the precedent of many of our annotation processors, which
 *       look for any annotation named, e.g., "GwtIncompatible," regardless of package.
 *   <li>An annotation named just "Suppress" might suggest to users that the test is suppressed

 * map from keys to <i>nonempty</i> collections of values:
 *
 * <ul>
 *   <li>a → 1, 2
 *   <li>b → 3
 * </ul>
 *
 * ... or as a single "flattened" collection of key-value pairs:
 *
 * <ul>
 *   <li>a → 1
 *   <li>a → 2
 *   <li>b → 3
 * </ul>
 *
 * <p><b>Important:</b> although the first interpretation resembles how most multimaps are

 *
 * <p>Advantages compared to {@code int[]}:
 *
 * <ul>
 *   <li>All the many well-known advantages of immutability (read <i>Effective Java</i>, third
 *       edition, Item 17).
 *   <li>Has the value-based (not identity-based) {@link #equals}, {@link #hashCode}, and {@link
 *       #toString} behavior you expect
 *   <li>Offers useful operations beyond just {@code get} and {@code length}, so you don't have to

  }

  /**
   * Verifies that a collection is immutable.
   *
   * <p>A collection is considered immutable if:
   *
   * <ol>
   *   <li>All its mutation methods result in UnsupportedOperationException, and do not change the
   *       underlying contents.
   *   <li>All methods that return objects that can indirectly mutate the collection throw
   *       UnsupportedOperationException when those mutators are called.
   * </ol>

 *
 * <p>Advantages compared to {@code double[]}:
 *
 * <ul>
 *   <li>All the many well-known advantages of immutability (read <i>Effective Java</i>, third
 *       edition, Item 17).
 *   <li>Has the value-based (not identity-based) {@link #equals}, {@link #hashCode}, and {@link
 *       #toString} behavior you expect.
 *   <li>Offers useful operations beyond just {@code get} and {@code length}, so you don't have to

 * Benchmarks (as of December 2011) show that:
 *
 * <ul>
 *   <li>for an unnested {@code lock()} and {@code unlock()}, a cycle detecting lock takes 38ns as
 *       opposed to the 24ns taken by a plain lock.
 *   <li>for nested locking, the cost increases with the depth of the nesting:
 *       <ul>
 *         <li>2 levels: average of 64ns per lock()/unlock()
 *         <li>3 levels: average of 77ns per lock()/unlock()

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *

   * consistentHash(h, n)} equals:
   *
   * <ul>
   *   <li>{@code n - 1}, with approximate probability {@code 1/n}
   *   <li>{@code consistentHash(h, n - 1)}, otherwise (probability {@code 1 - 1/n})
   * </ul>
   *
   * <p>This method is suitable for the common use case of dividing work among buckets that meet the
   * following conditions:
   *
   * <ul>
   *   <li>You want to assign the same fraction of inputs to each bucket.

   * class documentation above). This method is <i>generally expected</i>, but not absolutely
   * required, to have the following properties:
   *
   * <ul>
   *   <li>Its execution does not cause any observable side effects.
   *   <li>The computation is <i>consistent with equals</i>; that is, {@link Objects#equal
   *       Objects.equal}{@code (a, b)} implies that {@code predicate.apply(a) ==
   *       predicate.apply(b))}.