*   <li>equalsImpl: which implementation of array equality to use
 * </ul>
 *
 * <p><b>Important note:</b> the primary goal of this benchmark is to ensure that varying {@code
 * whereToDiffer} produces no observable change in performance. We want to make sure that the array
 * equals implementation is *not* short-circuiting to prevent timing-based attacks. Being fast is
 * only a secondary goal.
 *
 * @author Kurt Alfred Kluever
 */

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

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

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>Since the value collections are sets, the behavior of a {@code SetMultimap} is not specified
 * if key or value objects already present in the multimap change in a manner that affects
 * {@code equals} comparisons. Use caution if mutable objects are used as keys or values in a {@code
 * SetMultimap}.
 *

   *
   * <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><b>Warning:</b> The methods of {@code ForwardingSortedSet} forward <i>indiscriminately</i> to
 * the methods of the delegate. For example, overriding {@link #add} alone <i>will not</i> change
 * the behavior of {@link #addAll}, which can lead to unexpected behavior. In this case, you should
 * override {@code addAll} as well, either providing your own implementation, or delegating to the

 * compatibility (otherwise prefer {@link #putUnencodedChars}). However, the character encodings
 * must be identical across languages. Also beware that {@link Charset} definitions may occasionally
 * change between Java releases.
 *
 * <p><b>Warning:</b> Chunks of data that are put into the {@link Hasher} are not delimited. The
 * resulting {@link HashCode} is dependent only on the bytes inserted, and the order in which they