"tearDownTwo should have been run before tearDownOne", false, tearDownOne.ran);
          }
        };

    final SimpleTearDown tearDownTwo = new SimpleTearDown(callback);
    stack.addTearDown(tearDownTwo);

    assertEquals(false, tearDownOne.ran);
    assertEquals(false, tearDownTwo.ran);

    stack.runTearDown();

    assertEquals("tearDownOne should have run", true, tearDownOne.ran);

import java.lang.reflect.Method;
import java.util.Locale;
import junit.framework.TestCase;

/**
 * Since annotations have some reusability issues that force copy and paste all over the place, it's
 * worth having a test to ensure that all our Feature enums have their annotations correctly set up.
 *
 * @author George van den Driessche
 */
public class FeatureEnumTest extends TestCase {

  private final transient int size;

  /*
   * We have some considerable complexity in these create methods because of
   * Builder.buildKeepingLast(). The same Builder might be called with buildKeepingLast() and then
   * buildOrThrow(), or vice versa. So in particular, if we modify alternatingKeysAndValues to
   * eliminate duplicate keys (for buildKeepingLast()) then we have to ensure that a later call to

 * {@code SetMultimap} instead, two presidents would have vanished, and last names might or might
 * not appear in chronological order.
 *
 * <p><b>Warning:</b> instances of type {@code Multimap} may not implement {@link Object#equals} in
 * the way you expect. Multimaps containing the same key-value pairs, even in the same order, may or
 * may not be equal and may or may not have the same {@code hashCode}. The recommended subinterfaces

          @Override
          public void run() {
            assertFalse("previous tearDown should have run before setUp", setUpRan.getAndSet(true));
          }
        };
    Runnable tearDown =
        new Runnable() {
          @Override
          public void run() {
            assertTrue("setUp should have run", setUpRan.getAndSet(false));
          }
        };

          @Override
          public void run() {
            assertFalse("previous tearDown should have run before setUp", setUpRan.getAndSet(true));
          }
        };
    Runnable tearDown =
        new Runnable() {
          @Override
          public void run() {
            assertTrue("setUp should have run", setUpRan.getAndSet(false));
          }
        };

curiosity.

  `Soles and eels, of course,' the Gryphon replied rather
impatiently:  `any shrimp could have told you that.'

  `If I'd been the whiting,' said Alice, whose thoughts were
still running on the song, `I'd have said to the porpoise, "Keep
back, please:  we don't want YOU with us!"'

  `They were obliged to have him with them,' the Mock Turtle
said:  `no wise fish would go anywhere without a porpoise.'

    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.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    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.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    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.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>