* already in the multimap has no effect. See the {@link Multimap} documentation for information
 * common to all multimaps.
 *
 * <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link
 * Set} of values, while {@link #entries} returns a {@code Set} of map entries. Though the method
 * signature doesn't say so explicitly, the map returned by {@link #asMap} has {@code Set} values.
 *

/**
 * Adapter to convert an {@link Enumeration} to an {@link Iterator}.
 *
 * @author shot
 * @param <T> the element type
 */
public class EnumerationIterator<T> implements Iterator<T> {

    private Enumeration<T> enumeration = null;

    /**
     * Returns an {@link Iterable} that wraps an {@link Enumeration} for use in a for-each statement.
     *

   * future is {@linkplain Future#isDone() done}.
   *
   * <p>Prefer to create {@code ListenableFuture} instances with {@link SettableFuture}, {@link
   * MoreExecutors#listeningDecorator( java.util.concurrent.ExecutorService)}, {@link
   * ListenableFutureTask}, {@link AbstractFuture}, and other utilities over creating plain {@code
   * Future} instances to be upgraded to {@code ListenableFuture} after the fact.
   */

   * depend on the element values, such as a {@link SortedSet}, or on the insertion ordering, such
   * as a {@link LinkedHashSet}. All list tests and sorted-collection tests automatically specify
   * this feature.
   */
  KNOWN_ORDER,

  /**
   * Indicates that a collection has a different {@link Object#toString} representation than most

/**
 * An immutable array of {@code int} values, with an API resembling {@link List}.
 *
 * <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.

/**
 * An immutable array of {@code long} values, with an API resembling {@link List}.
 *
 * <p>Advantages compared to {@code long[]}:
 *
 * <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.

 * by multiple threads.
 *
 * <p>Popular escapers are defined as constants in classes like {@link
 * com.google.common.html.HtmlEscapers} and {@link com.google.common.xml.XmlEscapers}. To create
 * your own escapers extend this class and implement the {@link #escape(int)} method.
 *
 * @author David Beaumont
 * @since 15.0
 */
@GwtCompatible

   * method provides a {@link Set} implementation corresponding to any {@link Map} implementation.
   * There is no need to use this method on a {@link Map} implementation that already has a
   * corresponding {@link Set} implementation (such as {@link java.util.HashMap} or {@link
   * java.util.TreeMap}).
   *

   * shortcut for creating an empty list then calling {@link Iterables#addAll}.
   *
   * <p><b>Note:</b> if mutability is not required and the elements are non-null, use {@link
   * ImmutableList#copyOf(Iterable)} instead. (Or, change {@code elements} to be a {@link
   * FluentIterable} and call {@code elements.toList()}.)
   *
   * <p><b>Performance note:</b> {@link ArrayList} and {@link java.util.ArrayDeque} consistently

   * ordering of all views in the returned table, with {@link #putAll} following the {@link
   * Table#cellSet()} iteration order. However, if {@link #orderRowsBy} or {@link #orderColumnsBy}
   * is called, the views are sorted by the supplied comparators.
   *
   * <p>For empty or single-cell immutable tables, {@link #of()} and {@link #of(Object, Object,
   * Object)} are even more convenient.
   *