class Holder {

      int value = 2;
    }
    final Holder holder = new Holder();

    // This function adds the holder's value to the input value.
    Function<Integer, Integer> adder =
        new Function<Integer, Integer>() {
          @Override
          public Integer apply(Integer from) {
            return from + holder.value;
          }
        };

   * contention. See above for explanation. This method suffers the usual non-modularity problems of
   * optimistic retry code, relying on rechecked sets of reads.
   *
   * @param x the value
   * @param hc the hash code holder
   * @param wasUncontended false if CAS failed before call
   */
  final void retryUpdate(long x, @CheckForNull int[] hc, boolean wasUncontended) {
    int h;
    if (hc == null) {

    Collection<E> siblingCollection = new ArrayList<>();
    siblingCollection.add(sampleElement);

    Collection<E> copy = new ArrayList<>();
    // Avoid copy.addAll(collection), which runs afoul of an Android bug in older versions:
    // http://b.android.com/72073 http://r.android.com/98929
    Iterators.addAll(copy, collection.iterator());

    try {
      collection.add(sampleElement);

 *
 * <p><b>Key-grouped iteration.</b> All view collections follow the same iteration order. In all
 * current implementations, the iteration order always keeps multiple entries with the same key
 * together. Any creation method that would customarily respect insertion order (such as {@link
 * #copyOf(Multimap)}) instead preserves key-grouped order by inserting entries for an existing key
 * immediately after the last entry having that key.
 *

 *
 * <p><b>Key-grouped iteration.</b> All view collections follow the same iteration order. In all
 * current implementations, the iteration order always keeps multiple entries with the same key
 * together. Any creation method that would customarily respect insertion order (such as {@link
 * #copyOf(Multimap)}) instead preserves key-grouped order by inserting entries for an existing key
 * immediately after the last entry having that key.
 *

       * And, no, defining (final or not) local variables out of the loop still isn't as good
       * because the null check on the theUnsafe object remains inside the loop and
       * BYTE_ARRAY_BASE_OFFSET doesn't get constant-folded.
       *
       * The compiler can treat static final fields as compile-time constants and can constant-fold
       * them while (final or not) local variables are run time values.
       */

  @GwtIncompatible // SerializableTester
  public void testSerializationIndirectSelfReference() {
    Multiset<MultisetHolder> multiset = HashMultiset.create();
    MultisetHolder holder = new MultisetHolder(multiset);
    multiset.add(holder, 2);
    Multiset<MultisetHolder> copy = SerializableTester.reserialize(multiset);
    assertEquals(2, copy.size());
    assertSame(copy, copy.iterator().next().member);
  }

  /*

    IdentityLoader<Object> loader = identityLoader();
    for (int i = 1; i < 1000; i++) {
      LoadingCache<Object, Object> cache = CacheBuilder.newBuilder().maximumSize(i).build(loader);
      assertEquals(i, CacheTesting.getTotalSegmentSize(cache));
    }
  }

  public void testEviction_setMaxSegmentWeight() {
    IdentityLoader<Object> loader = identityLoader();
    for (int i = 1; i < 1000; i++) {

        continue; // These classes exist only for the GWT compiler, not to be used.
      }
      if (
      /*
       * At least one of the classes nested inside TypeResolverTest triggers a bug under older JDKs:
       * https://bugs.openjdk.org/browse/JDK-8215328 -> https://bugs.openjdk.org/browse/JDK-8215470

        continue; // These classes exist only for the GWT compiler, not to be used.
      }
      if (
      /*
       * At least one of the classes nested inside TypeResolverTest triggers a bug under older JDKs:
       * https://bugs.openjdk.org/browse/JDK-8215328 -> https://bugs.openjdk.org/browse/JDK-8215470