<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() {

   *     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

     * 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

  }

  public void testPowerSetIteration_manual() {
    ImmutableSet<Integer> elements = ImmutableSet.of(1, 2, 3);
    Set<Set<Integer>> powerSet = powerSet(elements);
    // The API doesn't promise this iteration order, but it's convenient here.
    Iterator<Set<Integer>> i = powerSet.iterator();
    assertEquals(ImmutableSet.of(), i.next());
    assertEquals(ImmutableSet.of(1), i.next());

       * template to be null (though we do handle that case gracefully at runtime). I've left this
       * one as it is because one of our users has defined a wrapper API around Preconditions,
       * declaring a checkState method that accepts a possibly null template. So we'd need to update
       * that user first.
       */
      @CheckForNull String errorMessageTemplate,