*/
  Collection<V> get(@ParametricNullness K key);

  /**
   * Returns a view collection of all <i>distinct</i> keys contained in this multimap. Note that the
   * key set contains a key if and only if this multimap maps that key to at least one value.
   *
   * <p>Changes to the returned set will update the underlying multimap, and vice versa. However,

   * <i>adding</i> to the returned set is not possible.
   */
  @Override
  public Set<K> keySet() {
    return super.keySet();
  }

  /**
   * Returns a collection of all values in the multimap. Changes to the returned collection will
   * update the underlying multimap, and vice versa.
   *

   * `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() {

  /*
   * 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

  // 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) {

    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()))

  /**
   * Returns a view of the complement of this {@code RangeSet}.
   *
   * <p>The returned view supports the {@link #add} operation if this {@code RangeSet} supports
   * {@link #remove}, and vice versa.
   */
  RangeSet<C> complement();

  /**
   * Returns a view of the intersection of this {@code RangeSet} with the specified range.
   *

    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())))