limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    assertEvents(
        "R0.00", // First comes the saved-up burst, which defaults to a 1-second burst (2 requests).
        "R0.00", "R0.00", // Now comes the free request.
        "R0.50", // Now it's 0.5 seconds per request.
        "R0.50");

    limiter.setRate(Double.POSITIVE_INFINITY);
    limiter.acquire();

 *       testlib), but why bother?
 *   <li>Stripping code entirely might help us keep under the method limit someday. Even if it never
 *       comes to that, it may at least help with build and startup times.
 * </ul>
 */
@Retention(CLASS)
@Target({ANNOTATION_TYPE, CONSTRUCTOR, FIELD, METHOD, TYPE})
@GwtCompatible

        return first.length() - second.length();
      } else {
        return first.compareTo(second);
      }
    }
  }

  /** Decreasing integer values. A {@code null} comes before any non-null value. */
  private static final Comparator<@Nullable Integer> DECREASING_INT_COMPARATOR =
      Ordering.<Integer>natural().reverse().<Integer>nullsFirst();

  private SetMultimap<String, Integer> create() {

    }
    if (that == aboveAll()) {
      return -1;
    }
    int result = Range.compareOrThrow(endpoint, that.endpoint);
    if (result != 0) {
      return result;
    }
    // same value. below comes before above
    return Booleans.compare(this instanceof AboveValue, that instanceof AboveValue);
  }

  C endpoint() {
    return endpoint;
  }

  @SuppressWarnings("unchecked") // catching CCE
  @Override

 * George: [Washington, Bush, Bush]
 * Grover: [Cleveland, Cleveland]        // Two, non-consecutive terms, rep'ing NJ!
 * ...
 * }</pre>
 *
 * <h3>Views</h3>
 *
 * <p>Much of the power of the multimap API comes from the <i>view collections</i> it provides.
 * These always reflect the latest state of the multimap itself. When they support modification, the

 * <p>In order to allow proper garbage collection of unused locks, the edges of the lock graph are
 * weak references.
 *
 * <p><strong>Performance</strong>
 *
 * <p>The extra bookkeeping done by cycle detecting locks comes at some cost to performance.
 * Benchmarks (as of December 2011) show that:
 *
 * <ul>
 *   <li>for an unnested {@code lock()} and {@code unlock()}, a cycle detecting lock takes 38ns as

      }
      if (lhs == null) {
        // lhs (null) comes just before justAfterNull.
        // If rhs is b, lhs comes first.
        if (rhs.equals(justAfterNull)) {
          return -1;
        }
        return justAfterNull.compareTo(rhs);
      }
      if (rhs == null) {
        // rhs (null) comes just before justAfterNull.
        // If lhs is b, rhs comes first.
        if (lhs.equals(justAfterNull)) {

    limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    limiter.acquire();
    assertEvents(
        "R0.00", // First comes the saved-up burst, which defaults to a 1-second burst (2 requests).
        "R0.00", "R0.00", // Now comes the free request.
        "R0.50", // Now it's 0.5 seconds per request.
        "R0.50");

    limiter.setRate(Double.POSITIVE_INFINITY);
    limiter.acquire();

 *       testlib), but why bother?
 *   <li>Stripping code entirely might help us keep under the method limit someday. Even if it never
 *       comes to that, it may at least help with build and startup times.
 * </ul>
 */
@Retention(CLASS)
@Target({ANNOTATION_TYPE, CONSTRUCTOR, FIELD, METHOD, TYPE})
@GwtCompatible

              sneakyThrow(new SomeCheckedException());
              throw new AssertionError(); // unreachable
            }
          }
        };

    // The first time, the sneakily-thrown exception comes out
    try {
      iter.hasNext();
      fail("No exception thrown");
    } catch (Exception e) {
      if (!(e instanceof SomeCheckedException)) {
        throw e;
      }
    }