private static final String E34 = "3-4";
  private static final String E44 = "4-4";
  private static final int NODE_COUNT = 20;
  private static final int EDGE_COUNT = 20;
  // TODO(user): Consider adding both error messages from here and {@link AbstractNetworkTest}
  // in one class (may be a utility class for error messages).
  private static final String ERROR_PARALLEL_EDGE = "connected by a different edge";

     * linear-time operation, and it can even have side effects. Thus, we limit the special case to
     * List, which is _even more likely_ to have size() implemented to be fast and side-effect-free.
     *
     * We could consider recognizing specific other collections as safe (like ImmutableCollection,
     * except ContiguousSet!) or as not worth this optimization (CopyOnWriteArrayList?).
     */
    if (parts instanceof List) {

   * any other derivation method on the original {@code ClosingFuture} instance.
   *
   * @param consumer a callback whose method will be called (using {@code executor}) when this
   *     operation is done
   */
  public void finishToValueAndCloser(
      ValueAndCloserConsumer<? super V> consumer, Executor executor) {
    checkNotNull(consumer);
    if (!compareAndUpdateState(OPEN, WILL_CREATE_VALUE_AND_CLOSER)) {

  // * Future completion can be observed if the waitersField field contains a TOMBSTONE

  // Timed Get
  // There are a few design constraints to consider
  // * We want to be responsive to small timeouts, unpark() has non trivial latency overheads (I
  //   have observed 12 micros on 64-bit linux systems to wake up a parked thread). So if the

   * be updated after modifications to {@code graph}.
   *
   * @since 33.1.0 (present with return type {@code Graph} since 20.0)
   */
  // TODO(b/31438252): Consider potential optimizations for this algorithm.
  public static <N> ImmutableGraph<N> transitiveClosure(Graph<N> graph) {
    ImmutableGraph.Builder<N> transitiveClosure =

   */
  public static class Builder<C extends Comparable<?>> {
    private final List<Range<C>> ranges;

    public Builder() {
      this.ranges = new ArrayList<>();
    }

    // TODO(lowasser): consider adding union, in addition to add, that does allow overlap

    /**
     * Add the specified range to this builder. Adjacent ranges are permitted and will be merged,

   * stripes (much like the birthday paradox, where much fewer than anticipated birthdays are needed
   * for a pair of them to match). Please consider carefully the implications of the number of
   * stripes, the intended concurrency level, and the typical number of keys used in a {@code
   * bulkGet(keys)} operation. See <a href="http://www.mathpages.com/home/kmath199.htm">Balls in

   * be updated after modifications to {@code graph}.
   *
   * @since 33.1.0 (present with return type {@code Graph} since 20.0)
   */
  // TODO(b/31438252): Consider potential optimizations for this algorithm.
  public static <N> ImmutableGraph<N> transitiveClosure(Graph<N> graph) {
    ImmutableGraph.Builder<N> transitiveClosure =

    Some tests need reflective access to the internals of these packages. It is only the
    tests themselves and not the code being tested that needs that access, though there's no
    obvious way to ensure that.

    We could consider arranging things so that only the tests we know need this would get
    the add-opens. Right now that doesn't seem worth the effort, though.
    -->
    <test.add.opens>
      --add-opens java.base/java.lang=ALL-UNNAMED

    Some tests need reflective access to the internals of these packages. It is only the
    tests themselves and not the code being tested that needs that access, though there's no
    obvious way to ensure that.

    We could consider arranging things so that only the tests we know need this would get
    the add-opens. Right now that doesn't seem worth the effort, though.
    -->
    <test.add.opens>
      --add-opens java.base/java.lang=ALL-UNNAMED