* whenever there is a chance the check may fail "in real life". Example:
 *
 * <pre>{@code
 * Bill bill = remoteService.getLastUnpaidBill();
 *
 * // In case bug 12345 happens again we'd rather just die
 * Verify.verify(bill.status() == Status.UNPAID,
 *     "Unexpected bill status: %s", bill.status());
 * }</pre>
 *
 * <h3>Comparison to alternatives</h3>
 *

    // If the class is accessible to the system ClassLoader (ClassLoader.getSystemClassLoader())
    // then FRQ does not bother to load Finalizer.class through a separate ClassLoader. That happens
    // in our test environment, which foils the purpose of this test, so we disable the logic for
    // our test by setting a static field. We are changing the field in the parallel version of FRQ

    assertThrows(IllegalArgumentException.class, () -> multiset.add(KEY, COUNT_TO_ADD));
  }

  /**
   * Simulate some of the races that can happen on add. We can't easily simulate the race that
   * happens when an {@link AtomicInteger#compareAndSet} fails, but we can simulate the case where
   * the putIfAbsent returns a non-null value, and the case where the replace() of an observed zero
   * fails.
   */

    } catch (IllegalArgumentException expected) {
    }
  }

  /**
   * If there's a bug in builder growth, we wouldn't know how to expose it. So, brute force the hell
   * out of it for a while and see what happens.
   */
  public void testBuilder_bruteForce() {
    for (int i = 0; i < reduceIterationsIfGwt(100); i++) {
      ImmutableIntArray.Builder builder = ImmutableIntArray.builder(RANDOM.nextInt(20));

   * instances. Note that the instances that would get smaller are the right set to care about
   * optimizing, because the rest have the option of calling `trimmed`.
   */

  private final transient int start; // it happens that we only serialize instances where this is 0
  private final int end; // exclusive

  private ImmutableLongArray(long[] array) {
    this(array, 0, array.length);
  }

    // methods executes the validation check, they all will, and thus we only need to test one of
    // them to ensure that the validation check happens and has the expected behavior.
    assertNodeRemovedFromGraphErrorMessage(
        assertThrows(IllegalStateException.class, n1AdjacentNodes::size));
    assertNodeRemovedFromGraphErrorMessage(

    // methods executes the validation check, they all will, and thus we only need to test one of
    // them to ensure that the validation check happens and has the expected behavior.
    assertNodeRemovedFromGraphErrorMessage(
        assertThrows(IllegalStateException.class, n1AdjacentNodes::size));
    assertNodeRemovedFromGraphErrorMessage(

    // being resumed. To avoid a flake in this scenario, calculate how long that thread actually
    // waited and assert based on that time. Empirically, the race where the thread ends up waiting
    // for 5.5 seconds happens about 2% of the time.
    boolean longWait = TimeUnit.NANOSECONDS.toSeconds(thread.timeSpentBlocked) >= 5;
    // Count how long it actually took to return; we'll accept any number between the expected delay

  public void testRemovalNotification_clear_basher() throws InterruptedException {
    // If a clear() happens close to the end of computation, one of two things should happen:
    // - computation ends first: the removal listener is called, and the cache does not contain the
    //   key/value pair
    // - clear() happens first: the removal listener is not called, and the cache contains the pair

                 * the map to change between that call and this one. But if that happens, the
                 * behavior is undefined because of the concurrent mutation.)
                 *
                 * (Our prototype checker happens to be "smart" enough to understand this for the
                 * *get* call in getValue but not for the *put* call here.)
                 *