* Therefore, we can always create our own TypeVariable.
         *
         * 2. Starting with JDK 7u51, the JDK TypeVariable implementations does not interoperate
         * with ours. Therefore, we have to be careful about whether we create our own TypeVariable:
         *
         * 2a. If the resolved types are identical to the original types, then we can return the

          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and

   *
   * <p><b>Note:</b> the values of the metrics are undefined in case of overflow (though it is
   * guaranteed not to throw an exception). If you require specific handling, we recommend
   * implementing your own stats collector.
   */
  public long requestCount() {
    return saturatedAdd(hitCount, missCount);
  }

  /** Returns the number of times {@link Cache} lookup methods have returned a cached value. */

   *
   * <p><b>Note:</b> the values of the metrics are undefined in case of overflow (though it is
   * guaranteed not to throw an exception). If you require specific handling, we recommend
   * implementing your own stats collector.
   */
  public long requestCount() {
    return saturatedAdd(hitCount, missCount);
  }

  /** Returns the number of times {@link Cache} lookup methods have returned a cached value. */

 * not</b> change the behavior of {@link #add(Object)}, which can lead to unexpected behavior. In
 * this case, you should override {@code add(Object)} as well, either providing your own
 * implementation, or delegating to the provided {@code standardAdd} method.
 *
 * <p><b>{@code default} method warning:</b> This class does <i>not</i> forward calls to {@code

   * loaded by this test and that will obviously remain loaded for as long as the test is running.
   * So in order to check ClassLoader garbage collection we need to create a new ClassLoader and
   * make it load its own version of FinalizableReferenceQueue. Then we need to interact with that
   * parallel version through reflection in order to exercise the parallel
   * FinalizableReferenceQueue, and then check that the parallel ClassLoader can be

     * before it has the chance, the test will fail. To avoid this, the main
     * thread calls this method, which waits until the service has performed
     * its own "running" check.
     */
    void awaitRunChecks() throws InterruptedException {
      assertTrue(
          "Service thread hasn't finished its checks. "
              + "Exception status (possibly stale): "

 * href="https://github.com/lukas-krecan/future-converter">Future Converter</a>.)
 *
 * <h3>Extension</h3>
 *
 * If you want a class like {@code FluentFuture} but with extra methods, we recommend declaring your
 * own subclass of {@link ListenableFuture}, complete with a method like {@link #from} to adapt an
 * existing {@code ListenableFuture}, implemented atop a {@link ForwardingListenableFuture} that

 * </ul>
 *
 * <h3>Implementations</h3>
 *
 * <ul>
 *   <li>{@link ImmutableListMultimap}
 *   <li>{@link ImmutableSetMultimap}
 *   <li>Configure your own mutable multimap with {@link MultimapBuilder}
 *   <li>{@link LinkedListMultimap} (for one unusual kind of mutable {@code Multimap})
 * </ul>
 *

   * AggregateFuture} attaches listeners that hold references to one or more inputs. And in the case
   * of {@link CombinedFuture}, the user-supplied callback usually has its own references to inputs.
   */
  /*
   * In certain circumstances, this field might theoretically not be visible to an afterDone() call
   * triggered by cancel(). For details, see the comments on the fields of TimeoutFuture.