result = "running=[DONE]";
    } else if (state instanceof Blocker) {
      result = "running=[INTERRUPTED]";
    } else if (state instanceof Thread) {
      // getName is final on Thread, no need to worry about exceptions
      result = "running=[RUNNING ON " + ((Thread) state).getName() + "]";
    } else {
      result = "running=[NOT STARTED YET]";
    }
    return result + ", " + toPendingString();
  }

    // TODO(cgdecker): Add CharSource.slice?
    StringBuilder builder = new StringBuilder();
    Reader reader = concatenated.openStream(); // no need to worry about closing
    for (int i = 0; i < 8; i++) {
      builder.append((char) reader.read());
    }
    assertEquals(expected, builder.toString());
  }

    // TODO(cgdecker): Add CharSource.slice?
    StringBuilder builder = new StringBuilder();
    Reader reader = concatenated.openStream(); // no need to worry about closing
    for (int i = 0; i < 8; i++) {
      builder.append((char) reader.read());
    }
    assertEquals(expected, builder.toString());
  }

 * }
 *
 * <h3>Comparison to alternatives</h3>
 *
 * <p><b>Note:</b> In some cases the differences explained below can be subtle. When it's unclear
 * which approach to use, <b>don't worry</b> too much about it; just pick something that seems
 * reasonable and it will be fine.
 *
 * <ul>
 *   <li>If checking whether the <i>caller</i> has violated your method or constructor's contract

   *
   * TODO: cpovirk - Is this an issue anywhere anymore? It looks to have been fixed for Java 8
   * (https://bugs.openjdk.org/browse/JDK-7121314) and before Lollipop
   * (https://r.android.com/47508). We *would* need to worry for J2KT, whose own concurrency support
   * is evolving (b/381065164, b/458160722), but this class is @J2ktIncompatible.
   *
   * 2. The superclass toArray() method declares the more general return type `@Nullable Object[]`,

   */
  public static <E> ImmutableSet<E> of(E e1) {
    return new SingletonImmutableSet<>(e1);
  }

  /*
   * TODO: b/315526394 - Skip the Builder entirely for the of(...) methods, since we don't need to
   * worry that we might trigger the fallback to the JDK-backed implementation? (The varargs one
   * _could_, so we could keep it as it is. Or we could convince ourselves that hash flooding is
   * unlikely in practice there, too.)
   */