<location>https://docs.oracle.com/javase/9/docs/api/</location>
            </offlineLink>
            <!-- The Checker Framework likewise would claim javax.annotations, despite providing only a subset of the JSR305 annotations, so it must likewise come after JSR305. -->
            <offlineLink>
              <url>https://checkerframework.org/api/</url>

import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.TimeoutException;
import junit.framework.TestCase;

/**
 * Tests for {@link FluentFuture}. The tests cover only the basics for the API. The actual logic is
 * tested in {@link FuturesTest}.
 */
@ElementTypesAreNonnullByDefault
@GwtCompatible(emulated = true)
public class FluentFutureTest extends TestCase {
  public void testFromFluentFuture() {

  // 2. Use Guava types in your public API:
  api("com.google.guava:guava:33.2.0-jre")

  // 3. Android - Use Guava in your implementation only:
  implementation("com.google.guava:guava:33.2.0-android")

  // 4. Android - Use Guava types in your public API:
  api("com.google.guava:guava:33.2.0-android")
}
```

For more information on when to use `api` and when to use `implementation`,
consult the

   *     neither fast nor secure. As of January 2017, we suggest:
   *     <ul>
   *       <li>For security:
   *           {@link Hashing#sha256} or a higher-level API.
   *       <li>For speed: {@link Hashing#goodFastHash}, though see its docs for caveats.
   *     </ul>
   */
  @Deprecated
  public static HashFunction md5() {
    return Md5Holder.MD5;
  }

public final class Monitor {
  // TODO(user): Use raw LockSupport or AbstractQueuedSynchronizer instead of ReentrantLock.
  // TODO(user): "Port" jsr166 tests for ReentrantLock.
  //
  // TODO(user): Change API to make it impossible to use a Guard with the "wrong" monitor,
  //    by making the monitor implicit, and to eliminate other sources of IMSE.
  //    Imagine:
  //    guard.lock();

     * it returns a subclass of Joiner that overrides this method to tolerate null inputs.
     *
     * Unfortunately, we don't distinguish between these two cases in our public API: Joiner.on(...)
     * and Joiner.on(...).useForNull(...) both declare the same return type: plain Joiner. To ensure
     * that users *can* pass null arguments to Joiner, we annotate it as if it always tolerates null

   *     directly, or use a combination of {@link #throwIfUnchecked} and {@code throw new
   *     RuntimeException(e)}. But consider whether users would be better off if your API threw a
   *     different type of exception. For background on the deprecation, read <a
   *     href="https://goo.gl/Ivn2kc">Why we deprecated {@code Throwables.propagate}</a>.
   */
  @CanIgnoreReturnValue

   *     directly, or use a combination of {@link #throwIfUnchecked} and {@code throw new
   *     RuntimeException(e)}. But consider whether users would be better off if your API threw a
   *     different type of exception. For background on the deprecation, read <a
   *     href="https://goo.gl/Ivn2kc">Why we deprecated {@code Throwables.propagate}</a>.
   */
  @CanIgnoreReturnValue

   *
   * <p>If all input data to this {@code TopKSelector} is in a single {@code Iterable}, prefer
   * {@link Ordering#leastOf(Iterable, int)}, which provides a simpler API for that use case.
   */
  public void offerAll(Iterable<? extends T> elements) {
    offerAll(elements.iterator());
  }

  /**

     * a fan of that: What if we someday implement (presumably to be enabled during tests only)
     * bytecode rewriting that checks for any null value that passes through an API with a
     * known-non-null type? But that particular problem might not arise here, since we're not
     * actually reading from the fields in any case in which they might be null (as proven by the