// It is possible due to races that we are currently in the expected state even though we
      // timed out. e.g. if we weren't event able to grab the lock within the timeout we would never
      // even check the guard. I don't think we care too much about this use case but it could lead
      // to a confusing error message.
      throw new TimeoutException("Timed out waiting for " + this + " to reach the RUNNING state.");
    }
  }

  @Override

       * doesn't need access to the futures again, so we can just pass `null`.
       *
       * TODO(b/112550045): Allocating a single, cheaper listener is (I think) only an optimization.
       * If we make some other optimizations, this one will no longer be necessary. The optimization
       * could actually hurt in some cases, as it forces us to keep all inputs in memory until the

      // It is possible due to races that we are currently in the expected state even though we
      // timed out. e.g. if we weren't event able to grab the lock within the timeout we would never
      // even check the guard. I don't think we care too much about this use case but it could lead
      // to a confusing error message.
      throw new TimeoutException("Timed out waiting for " + this + " to reach the RUNNING state.");
    }
  }

  @Override

  `Headers.of(String...)` with `headersOf(vararg String)`.

#### Extension Functions

We’ve migrated from static functions to extension functions where we think they fit.

| Java                                | Kotlin                          |
| :---------------------------------- | :------------------------------ |

          </excludePackageNames>
          <!-- Ignore some tags that are found in Java 11 sources but not recognized... under -source 8, I think it was? I can no longer reproduce the failure. -->
          <tags>
            <tag>
              <name>apiNote</name>
              <placement>X</placement>
            </tag>
            <tag>

   */
  // Note: 90% of the time we don't add type parameters or wildcards that serve only to "tweak" the
  // desired return type. However, *nested* generics introduce a special class of problems that we
  // think tip it over into being worthwhile.
  public static <T extends @Nullable Object, S extends T> Comparator<Iterable<S>> lexicographical(
      Comparator<T> comparator) {

     */
    @Override
    public String getHostName() {
        /*
         * 2010 - We no longer try a Node Status to get the
         * hostname because apparently some servers do not respond
         * anymore. I think everyone post Windows 98 will accept
         * an IP address as the tconHostName which is the principal
         * use of this method.
         */
        if (this.hostName.isUnknown()) {

        return JAVA7.usedInGenericType(type);
      }

      /*
       * We use this only when getTypeName is available.
       *
       * Well, really, we use this when we think we're running under Java 8, as determined by some
       * logic in the static initializer, which does not check for getTypeName specifically. We

             * request. However the chances are slim and the
             * retry code should ensure the overall request
             * is serviced. The alternative complicates things
             * more than I think is worth it.
             */

            if (socket != null) {
                socket.close();
                socket = null;
            }
            thread = null;
            responseTable.clear();

        }
      } finally {
        // Important to null this out here - if we did *not* execute inline, we might still
        // run() on the same thread that called execute() - such as in a thread pool, and think
        // that it was happening inline. As a side benefit, avoids holding on to the Thread object
        // longer than necessary.
        submitting = null;
      }
    }