* iterator} method only once, and should be tested using this class. Exceptions to this rule should
 * be clearly documented.
 *
 * <p>Note that although your APIs should be liberal in what they accept, your methods which
 * <i>return</i> iterables should make every attempt to return ones of the robust variety.
 *
 * <p>This testing utility is not thread-safe.
 *
 * @author Kevin Bourrillion

public class AbstractListTester<E extends @Nullable Object> extends AbstractCollectionTester<E> {
  /*
   * Previously we had a field named list that was initialized to the value of
   * collection in setUp(), but that caused problems when a tester changed the
   * value of list or collection but not both.
   */
  protected final List<E> getList() {
    return (List<E>) collection;
  }

  /**

  }

  /**
   * Returns the {@link Method} instance for {@link #testAddAll_unsupportedNonePresent()} so that
   * tests can suppress it with {@code FeatureSpecificTestSuiteBuilder.suppressing()} while we
   * figure out what to do with <a href="http://goo.gl/qJBruX">{@code ConcurrentHashMap} support for
   * {@code entrySet().add()}</a>.
   */
  @J2ktIncompatible

start by opening a new issue describing the bug or feature you're intending to
fix. Even if you think it's relatively minor, it's helpful to know what people
are working on. And as mentioned above, API changes should be discussed
thoroughly before moving to code.

Some examples of types of pull requests that are immediately helpful:

  - Fixing a bug without changing a public API.
  - Fixing or improving documentation.

   * cannot implement that interface in source code in a way that will compile on both Java 7 and
   * Java 8. If we include the {@code getAnnotatedBounds()} method then its return type means it
   * won't compile on Java 7, while if we don't include the method then the compiler will complain

   *       {@code MapJoiner} method that accepts entries as input, and receive output of the form
   *       {@code key1=A&key1=B&key2=C}.
   *   <li>To output a single entry for each key, pass {@code multimap.asMap()} to a {@code
   *       MapJoiner} method that accepts a map as input, and receive output of the form {@code
   *       key1=[A, B]&key2=C}.
   * </ul>
   *

     * requires us to define extra classes -- unfortunate under Android.) *Then* we could consider
     * lying about the fields below on the grounds that we always initialize them just after the
     * constructor -- an example of the kind of lying that our hypothetical bytecode rewriter would
     * already have to deal with, thanks to DI frameworks that perform field and method injection,

  // could find them in the code review archives), but here are a few:
  //
  // 1. What about leaving/unlocking? Are you going to do
  //    guard.enter() paired with monitor.leave()? That might get
  //    confusing. It's nice for the finally block to look as close as
  //    possible to the thing right before the try. You could have
  //    guard.leave(), but that's a little odd as well because the

import java.util.Iterator;
import java.util.NavigableSet;
import java.util.SortedSet;
import java.util.TreeSet;
import org.checkerframework.checker.nullness.qual.Nullable;

/**
 * A wrapper around {@code TreeSet} that aggressively checks to see if elements are mutually
 * comparable. This implementation passes the navigable set test suites.
 *
 * @author Louis Wasserman
 */
@GwtIncompatible

   *
   * <p><b>Note:</b> Despite what the method name suggests, if {@code elements} is an {@code
   * ImmutableSortedSet}, it may be returned instead of a copy.
   *
   * <p>This method is not type-safe, as it may be called on elements that are not mutually
   * comparable.
   *
   * <p>This method is safe to use even when {@code elements} is a synchronized or concurrent
   * collection that is currently being modified by another thread.