*/
@GwtCompatible
@Ignore // Affects only Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
public class ListIndexOfTester<E> extends AbstractListIndexOfTester<E> {
  @Override
  protected int find(Object o) {
    return getList().indexOf(o);
  }

  @Override
  protected String getMethodName() {
    return "indexOf";
  }

  @CollectionFeature.Require(absent = REJECTS_DUPLICATES_AT_CREATION)

    writing it has test supersource but no prod supersource.

    GWT happens to use the prod .gwt.xml, so it looks for no supersource for
    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

  // earlier versions of Monitor even did something like this. I ended
  // up strongly favoring the current interface.
  //
  // I probably can't remember all the reasons (it's possible you
  // 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

  /**
   * Returns a {@code URL} pointing to {@code resourceName} if the resource is found using the
   * {@linkplain Thread#getContextClassLoader() context class loader}. In simple environments, the
   * context class loader will find resources from the class path. In environments where different
   * threads can have different class loaders, for example app servers, the context class loader

 *         .catching(RpcException.class, e -> false, directExecutor());
 * }</pre>
 *
 * <h3>Alternatives</h3>
 *
 * <h4>Frameworks</h4>
 *
 * <p>When chaining together a graph of asynchronous operations, you will often find it easier to
 * use a framework. Frameworks automate the process, often adding features like monitoring,
 * debugging, and cancellation. Examples of frameworks include:
 *
 * <ul>

 * UnicodeEscaper}. They are heavily optimized for performance and greatly simplify the task of
 * implementing new escapers. It is strongly recommended that when implementing a new escaper you
 * extend one of these classes. If you find that you are unable to achieve the desired behavior
 * using either of these classes, please contact the Java libraries team for advice.
 *
 * <p>Popular escapers are defined as constants in classes like {@link

   * The pointer to a key is stored in hashTable[Hashing.smear(key.hashCode()) % table.length],
   * save that if that location is already full, we try the next index, and the next, until we
   * find an empty table position.  Since the table has a power-of-two size, we use
   * & (table.length - 1) instead of % table.length, though.
   */

  @CheckForNull private final transient Object hashTable;

 * Futures#transform(ListenableFuture, com.google.common.base.Function, Executor) Futures.transform}
 * (or {@link FluentFuture#transform(com.google.common.base.Function, Executor)
 * FluentFuture.transform}), but you will often find it easier to use a framework. Frameworks
 * automate the process, often adding features like monitoring, debugging, and cancellation.
 * Examples of frameworks include:
 *
 * <ul>

   * Returns the first of two given parameters that is not {@code null}, if either is, or otherwise
   * throws a {@link NullPointerException}.
   *
   * <p>To find the first non-null element in an iterable, use {@code Iterables.find(iterable,
   * Predicates.notNull())}. For varargs, use {@code Iterables.find(Arrays.asList(a, b, c, ...),
   * Predicates.notNull())}, static importing as necessary.
   *

    writing it has test supersource but no prod supersource.

    GWT happens to use the prod .gwt.xml, so it looks for no supersource for
    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.