MoreObjects.toStringHelper(new TestClass())
            .add("field1", "This is string.")
            .add("field2", Arrays.asList("abc", "def", "ghi"))
            .add("field3", map)
            .toString();
    final String expected =
        "TestClass{"
            + "field1=This is string., field2=[abc, def, ghi], field3={abc=1, def=2, ghi=3}}";

    assertEquals(expected, toTest);
  }

    extends AggregateFuture<V, C> {
  /*
   * We access this field racily but safely. For discussion of a similar situation, see the comments
   * on the fields of TimeoutFuture. This field is slightly different from the fields discussed
   * there: cancel() never reads this field, only writes to it. That makes the race here completely
   * harmless, rather than just 99.99% harmless.
   */

     * we can reference a node whose fields have been cleared is inside the iterator (and presumably
     * only under concurrent modification).
     *
     * To access these fields when you know that they are not null, call the pred() and succ()
     * methods, which perform null checks before returning the fields.
     */
    @CheckForNull private AvlNode<E> pred;

    @CheckForNull ValueEntry<K, V> nextInValueBucket;
    /*
     * The *InValueSet and *InMultimap fields below are null after construction, but we almost
     * always call succeedsIn*() to initialize them immediately thereafter.
     *
     * The exception is the *InValueSet fields of multimapHeaderEntry, which are never set. (That

   *
   * Then we declare the getters for these fields as @GwtIncompatible so that no one can try to use
   * them under J2CL—or, as an unfortunate side effect, under GWT. We do still give the fields
   * themselves their proper values under GWT, since GWT's EnumMap does need the Class instance.
   *
   * Note that sometimes these fields *do* have correct values under J2CL: They will if the caller

        MoreObjects.toStringHelper(new TestClass())
            .add("field1", "This is string.")
            .add("field2", Arrays.asList("abc", "def", "ghi"))
            .add("field3", map)
            .toString();
    final String expected =
        "TestClass{"
            + "field1=This is string., field2=[abc, def, ghi], field3={abc=1, def=2, ghi=3}}";

    assertEquals(expected, toTest);
  }

    @Override
    @ParametricNullness
    public T get() {
      // Another variant of Double Checked Locking.
      //
      // We use two volatile reads. We could reduce this to one by
      // putting our fields into a holder class, but (at least on x86)
      // the extra memory consumption and indirection are more
      // expensive than the extra volatile reads.
      long nanos = expirationNanos;

    checkHelperVersion(NO_ATOMIC_FIELD_UPDATER, "SynchronizedAtomicHelper");

    // Run the corresponding FuturesTest test method in a new classloader that disallows
    // certain core jdk classes.
    ClassLoader oldClassLoader = Thread.currentThread().getContextClassLoader();
    Thread.currentThread().setContextClassLoader(NO_ATOMIC_FIELD_UPDATER);
    try {
      runTestMethod(NO_ATOMIC_FIELD_UPDATER);

   * next} field is lazily initialized. The type of that field would be {@code @Nullable T}, and the
   * code would be responsible for populating a "real" {@code T} (which might still be the value
   * {@code null}!) before returning it to callers. Depending on how the code is structured, a
   * nullness analysis might not understand that the field has been populated. To avoid that problem

    }
  }

  // Instance stuff here

  // The array is never mutated after storing in this field and the construction strategies ensure
  // it doesn't escape this class
  @SuppressWarnings("Immutable")
  private final int[] array;

  /*
   * TODO(kevinb): evaluate the trade-offs of going bimorphic to save these two fields from most
   * instances. Note that the instances that would get smaller are the right set to care about