* }</pre>
 *
 * <h3>Views</h3>
 *
 * <p>Much of the power of the multimap API comes from the <i>view collections</i> it provides.
 * These always reflect the latest state of the multimap itself. When they support modification, the
 * changes are <i>write-through</i> (they automatically update the backing multimap). These view
 * collections are:
 *
 * <ul>
 *   <li>{@link #asMap}, mentioned above

   * AtomicInteger's atomic operations, with some help from ConcurrentMap's atomic operations on
   * creation and removal (including automatic removal of zeroes). If the modification of an
   * AtomicInteger results in zero, we compareAndSet the value to zero; if that succeeds, we remove
   * the entry from the Map. If another operation sees a zero in the map, it knows that the entry is

      /*
       * requireNonNull is safe as long as callers pass a nextSibling that (a) has the same key and
       * (b) is present in the multimap. (And they do, except maybe in case of concurrent
       * modification, in which case all bets are off.)
       */
      KeyList<K, V> keyList = requireNonNull(keyToKeyList.get(key));
      keyList.count++;
      node.previous = nextSibling.previous;

   * AtomicInteger's atomic operations, with some help from ConcurrentMap's atomic operations on
   * creation and removal (including automatic removal of zeroes). If the modification of an
   * AtomicInteger results in zero, we compareAndSet the value to zero; if that succeeds, we remove
   * the entry from the Map. If another operation sees a zero in the map, it knows that the entry is

   * implementation-dependent). Furthermore, implementations are not required to support
   * modifications to the entry set at all, and the {@code Entry} instances themselves don't even
   * have methods for modification. See the specific implementation class for more details on how
   * its entry set handles modifications.
   *
   * @return a set of entries representing the data of this multiset
   */
  Set<Entry<E>> entrySet();

   * implementation-dependent). Furthermore, implementations are not required to support
   * modifications to the entry set at all, and the {@code Entry} instances themselves don't even
   * have methods for modification. See the specific implementation class for more details on how
   * its entry set handles modifications.
   *
   * @return a set of entries representing the data of this multiset
   */
  Set<Entry<E>> entrySet();

  /**
   * Returns a copy of the input string in which all {@linkplain #isUpperCase(char) uppercase ASCII
   * characters} have been converted to lowercase. All other characters are copied without
   * modification.
   */
  public static String toLowerCase(String string) {
    int length = string.length();
    for (int i = 0; i < length; i++) {
      if (isUpperCase(string.charAt(i))) {

   * #add(Range) add} any range not {@linkplain Range#encloses(Range) enclosed} by {@code view}.
   */
  RangeSet<C> subRangeSet(Range<C> view);

  // Modification

  /**
   * Adds the specified range to this {@code RangeSet} (optional operation). That is, for equal
   * range sets a and b, the result of {@code a.add(range)} is that {@code a} will be the minimal

       *   to iterate it to exhaustion. Then we can apply the logic above about an empty
       *   columnIterator. (This assumes no concurrent modification, but behavior under concurrent
       *   modification is undefined, anyway.)
       */
      requireNonNull(rowEntry);
      Entry<C, V> columnEntry = columnIterator.next();

 * will change the table.
 *
 * <p>All methods that modify the table are optional, and the views returned by the table may or may
 * not be modifiable. When modification isn't supported, those methods will throw an {@link
 * UnsupportedOperationException}.
 *
 * <h3>Implementations</h3>
 *
 * <ul>
 *   <li>{@link ImmutableTable}
 *   <li>{@link HashBasedTable}