things you should know about contributing:

1.  API changes require discussion, use cases, etc. Code comes later.
2.  Pull requests are great for small fixes for bugs, documentation, etc.
3.  Pull requests are not merged directly into the master branch.
4.  Code contributions require signing a Google CLA.

API changes
-----------

We make changes to Guava's public [APIs][], including adding new APIs, very

  /**
   * 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>
   *

   * class to begin with but rather something returned from a static factory method whose declared
   * return type is plain FilenameFilter. If we made such a change, then the annotation we choose
   * here would have no significance to end users, who would be forced to conform to the signature
   * used in FilenameFilter.)
   */
  @Override

import java.util.SortedSet;
import java.util.stream.Collector;
import javax.annotation.CheckForNull;
import org.checkerframework.checker.nullness.qual.Nullable;

/**
 * A {@link NavigableSet} whose contents will never change, with many other important properties
 * detailed at {@link ImmutableCollection}.
 *
 * <p><b>Warning:</b> as with any sorted collection, you are strongly advised not to use a {@link

 *
 * <p><b>Warning:</b> The methods of {@code ForwardingMapEntry} forward <i>indiscriminately</i> to
 * the methods of the delegate. For example, overriding {@link #getValue} alone <i>will not</i>
 * change the behavior of {@link #equals}, which can lead to unexpected behavior. In this case, you
 * should override {@code equals} as well, either providing your own implementation, or delegating

    // Note that it's possible in future that the JDK's idea to toUpperCase() or equalsIgnoreCase()
    // may change and break assumptions in this test [*]. This is not a bug in the implementation of
    // Ascii.equalsIgnoreCase(), but it is a signal that its documentation may need updating as
    // regards edge cases.

   *
   * <p><b>Warning:</b> a new random seed for these functions is chosen each time the {@code
   * Hashing} class is loaded. <b>Do not use this method</b> if hash codes may escape the current
   * process in any way, for example being sent over RPC, or saved to disk. For a general-purpose,
   * non-cryptographic hash function that will never change behavior, we suggest {@link

 *
 * <p>The classes in this package include:
 *
 * <h2>Immutable collections</h2>
 *
 * These are collections whose contents will never change. They also offer a few additional
 * guarantees (see {@link ImmutableCollection} for details). Implementations are available for both
 * the JDK collection types and the Guava collection types (listed below).
 *

   * In JDK 1.7.0_51-b13, {@link TypeVariableImpl#equals(Object)} is changed to no longer be equal
   * to custom TypeVariable implementations. As a result, we need to make sure our TypeVariable
   * implementation respects symmetry. Moreover, we don't want to reconstruct a native type variable
   * {@code <A>} using our implementation unless some of its bounds have changed in resolution. This

 *
 * <p><b>Warning:</b> The methods of {@code ForwardingSortedMultiset} forward
 * <b>indiscriminately</b> to the methods of the delegate. For example, overriding {@link
 * #add(Object, int)} alone <b>will not</b> change the behavior of {@link #add(Object)}, which can
 * lead to unexpected behavior. In this case, you should override {@code add(Object)} as well,
 * either providing your own implementation, or delegating to the provided {@code standardAdd}