}

  @Override
  public Collection<V> values() {
    return delegate.values();
  }

  @CanIgnoreReturnValue
  private <T> T checkValid(T t) {
    // a ClassCastException is what's supposed to happen!
    @SuppressWarnings("unchecked")
    K k = (K) t;
    int unused = comparator().compare(k, k);
    return t;
  }

  @Override
  public boolean equals(@Nullable Object obj) {

 *
 * <p>Tests should inherit from this class, and declare subtyping relationship with public methods
 * annotated by {@link TestSubtype}.
 *
 * <p>These declaration methods rely on Java static type checking to make sure what we want to
 * assert as subtypes are really subtypes according to javac. For example:
 *
 * <pre>{@code
 * class MySubtypeTests extends SubtypeTester {
 *   @TestSubtype(suppressGetSubtype = true, suppressGetSupertype = true)

     * a no-op. We could log, but if that's what we really want, we should modify
     * AbstractFuture.executeListener to do so, since that method would have the ability to continue
     * to execute other listeners.
     *
     * What about RuntimeException? If there is a bug in set()/setValue() that produces one, it will

     * implementations, supports add() under JDK8. This seems problematic, but I
     * didn't see that discussed in the review, which included many other
     * changes: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make
     * entrySet().add() tests tolerant of either behavior, introduce a map

    try {
      ForwardingObjectTester.testForwardingObject(FailToForward.class);
    } catch (AssertionError | UnsupportedOperationException expected) {
      // UnsupportedOperationException is what we see on Android.
      return;
    }
    fail("Should have thrown");
  }

  @AndroidIncompatible // TODO(cpovirk): java.lang.IllegalAccessError: superclass not accessible
  public void testSuccessfulForwarding() {

     * implementations, supports add() under JDK8. This seems problematic, but I
     * didn't see that discussed in the review, which included many other
     * changes: http://goo.gl/okTTdr
     *
     * TODO(cpovirk): decide what the best long-term action here is: force users
     * to suppress (as we do now), stop testing entrySet().add() at all, make
     * entrySet().add() tests tolerant of either behavior, introduce a map

  }

  @SuppressWarnings("unused") // compilation test
  public void testSampleCodeFine2() {
    FluentIterable<? extends Number> numbers = getSomeNumbers();

    // Sadly, the following is what users will have to do in some circumstances.

    @SuppressWarnings("unchecked") // safe covariant cast
    Optional<Number> first = (Optional<Number>) numbers.first();
    Number value = first.or(0.5); // fine
  }

 * elements' text contents must not be HTML escaped</a>. As a result, it is impossible to escape an
 * HTML document correctly without domain-specific knowledge beyond what {@code HtmlEscapers}
 * provides. We strongly encourage the use of HTML templating systems.
 *
 * @author Sven Mawson
 * @author David Beaumont
 * @since 15.0
 */
@GwtCompatible
@ElementTypesAreNonnullByDefault

    String data = "Hi There";

    checkSha1("b617318655057264e28bc0b6fb378c8ef146be00", key, data);
  }

  public void testRfc2202_hmacSha1_case2() {
    byte[] key = "Jefe".getBytes(UTF_8);
    String data = "what do ya want for nothing?";

    checkSha1("effcdf6ae5eb2fa2d27416d5f184df9c259a7c79", key, data);
  }

  public void testRfc2202_hmacSha1_case3() {
    byte[] key = fillByteArray(20, 0xaa);

    assertEvents(
        "R0.00, R1.38, R1.13, R0.88, R0.63, R0.50, R0.50, R0.50", // #1
        "U4.50", // #2
        "R0.00, R1.38, R1.13", // #3, after that the rate changes
        "R0.88", // #4, this is what the throttling would be with the old rate
        "R0.34, R0.28, R0.25, R0.25", // #5
        "U4.25", // #6
        "R0.00, R0.72, R0.66, R0.59, R0.53, R0.47, R0.41", // #7