@Ignore // Affects only Android test runner, which respects JUnit 4 annotations on JUnit 3 tests.
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;
    }
    out.write(data);
    assertTrue(Arrays.equals(data, source.read()));

    out.close();
    assertThrows(IOException.class, () -> out.write(42));

    // Verify that write had no effect
    assertTrue(Arrays.equals(data, source.read()));
    out.reset();
  }

  public void testReset() throws Exception {
    byte[] data = newPreFilledByteArray(100);

 * they return from {@code get} behave like (and, of course, implement) {@link List} and {@link
 * Set}, respectively.
 *
 * <p>For example, the "presidents" code snippet above used a {@code ListMultimap}; if it had used a
 * {@code SetMultimap} instead, two presidents would have vanished, and last names might or might
 * not appear in chronological order.
 *

   * eliminate duplicate keys (for buildKeepingLast()) then we have to ensure that a later call to
   * buildOrThrow() will still throw as if the duplicates had not been eliminated. And the exception
   * message must mention two values that were associated with the duplicate key in two different
   * calls to Builder.put (though we don't really care *which* two values if there were more than

 *
 * <p>This version adds some verbosity around the {@code Guard} objects, but removes that same
 * verbosity, and more, from the {@code get} and {@code set} methods. {@code Monitor} implements the
 * same efficient signaling as we had to hand-code in the {@code ReentrantLock} version above.
 * Finally, the programmer no longer has to hand-code the wait loop, and therefore doesn't have to
 * remember to use {@code while} instead of {@code if}.
 *

   *
   * However, for a variety of reasons, Google developers have written a ton of code over the past
   * decade that assumes that they can use checkNotNull for non-precondition checks. I had hoped to
   * take a principled stand on this, but the amount of such code is simply overwhelming. To avoid
   * creating a lot of compile errors that users would not find to be informative, we're giving in

 * that is how the signature looked even prior to this comment! So naturally any change can break
 * existing users, but it can't *fix* existing users because any users who needed
 * `Function<@Nullable A, @Nullable B>` already had to find a workaround. Still, there is a *ton* of
 * fallout from trying to switch. I would be shocked if the switch would offer benefits to anywhere
 * near enough users to justify the costs.
 *

    final Object localValue = value;
    return localValue instanceof Cancellation;
  }

  /**
   * {@inheritDoc}
   *
   * <p>If a cancellation attempt succeeds on a {@code Future} that had previously been {@linkplain
   * #setFuture set asynchronously}, then the cancellation will also be propagated to the delegate
   * {@code Future} that was supplied in the {@code setFuture} call.
   *

  static <E> Queue<E> discardingQueue() {
    return (Queue) DISCARDING_QUEUE;
  }

  /*
   * Note: All of this duplicate code sucks, but it saves a lot of memory. If only Java had mixins!
   * To maintain this code, make a change for the strong reference type. Then, cut and paste, and
   * replace "Strong" with "Soft" or "Weak" within the pasted text. The primary difference is that

    bulkFuture.addListener(
        new Runnable() {
          @Override
          public void run() {
            /*
             * firstFuture just completed, but AggregateFuture hasn't yet had time to record the
             * exception in seenExceptions. When we complete secondFuture with the same exception,
             * we want for AggregateFuture to still detect that it's been previously seen.
             */