"four", 4,
            "five", 5,
            "six", 6,
            "seven", 7,
            "eight", 8,
            "nine", 9),
        "eight",
        8,
        "five",
        5,
        "four",
        4,
        "nine",
        9,
        "one",
        1,
        "seven",
        7,
        "six",
        6,
        "three",
        3,

   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple
   * `Integer.valueOf` calls into one! So we stick with the deprecated `Integer` constructor.
   */

  public void testEqualsEquivalent() {

  public static final Integer five = 5;
  public static final Integer six = 6;
  public static final Integer seven = 7;
  public static final Integer eight = 8;
  public static final Integer nine = 9;
  public static final Integer m1 = -1;
  public static final Integer m2 = -2;
  public static final Integer m3 = -3;
  public static final Integer m4 = -4;
  public static final Integer m5 = -5;

  // could find them in the code review archives), but here are a few:
  //
  // 1. What about leaving/unlocking? Are you going to do
  //    guard.enter() paired with monitor.leave()? That might get
  //    confusing. It's nice for the finally block to look as close as
  //    possible to the thing right before the try. You could have
  //    guard.leave(), but that's a little odd as well because the

  private static <E extends @Nullable Object> boolean addAllImpl(
      Multiset<E> self, Multiset<? extends E> elements) {
    // It'd be nice if we could specialize for ImmutableMultiset here without also retaining
    // its code when it's not in scope...
    if (elements instanceof AbstractMapBasedMultiset) {

            "seven", 7,
            "eight", 8,
            "nine", 9),
        "one",
        1,
        "two",
        2,
        "three",
        3,
        "four",
        4,
        "five",
        5,
        "six",
        6,
        "seven",
        7,
        "eight",
        8,
        "nine",
        9);
    assertMapEquals(
        ImmutableBiMap.of(

    int h2 = Objects.hashCode(Integer.valueOf(1), new String("two"), Double.valueOf(3.0));
    // repeatable
    assertEquals(h1, h2);

    // These don't strictly need to be true, but they're nice properties.
    assertTrue(Objects.hashCode(1, 2, null) != Objects.hashCode(1, 2));
    assertTrue(Objects.hashCode(1, 2, null) != Objects.hashCode(1, null, 2));
    assertTrue(Objects.hashCode(1, null, 2) != Objects.hashCode(1, 2));

            .withTearDown(parentBuilder.getTearDown())
            .createTestSuite());
    /*
     * TODO(cpovirk): the Map tests duplicate most of this effort by using a
     * CollectionTestSuiteBuilder on values(). It would be nice to avoid that
     */
    derived.add(
        SetTestSuiteBuilder.using(
                new BiMapValueSetGenerator<K, V>(parentBuilder.getSubjectGenerator()))

            "seven", 7,
            "eight", 8,
            "nine", 9),
        "one",
        1,
        "two",
        2,
        "three",
        3,
        "four",
        4,
        "five",
        5,
        "six",
        6,
        "seven",
        7,
        "eight",
        8,
        "nine",
        9);
    assertMapEquals(
        ImmutableMap.of(

    Collections.shuffle(hashCodes);
    HashCode hashCode2 = Hashing.combineUnordered(hashCodes);

    assertEquals(hashCode1, hashCode2);
  }

  // This isn't specified by contract, but it'll still be nice to know if this behavior changes.
  public void testConcatenating_equals() {
    new EqualsTester()
        .addEqualityGroup(Hashing.concatenating(asList(Hashing.md5())))