* version.
   *
   * @throws UnsupportedOperationException always
   * @deprecated <b>Pass a key of type {@code Comparable} to use {@link
   *     ImmutableSortedMap#of(Comparable, Object)}.</b>
   */
  @DoNotCall("Pass a key of type Comparable")
  @Deprecated
  public static <K, V> ImmutableSortedMap<K, V> of(K k1, V v1) {
    throw new UnsupportedOperationException();

    list.add("a");
    list.add("b");
    Iterator<String> iterator = list.iterator();
    try {
      get(iterator, -1, "c");
      fail();
    } catch (IndexOutOfBoundsException expected) {
      // pass
    }
    assertTrue(iterator.hasNext());
  }

  public void testAdvance_basic() {
    List<String> list = newArrayList();
    list.add("a");
    list.add("b");

   * take a principled stand on this, but the amount of such code is simply overwhelming. To avoid
   * creating a lot of compile errors that users would not find to be informative, we're giving in
   * and allowing callers to pass arguments that a nullness checker believes could be null.
   *
   * We still encourage people to use requireNonNull over checkNotNull for non-precondition checks.
   */

  /**

   * version.
   *
   * @throws UnsupportedOperationException always
   * @deprecated <b>Pass a key of type {@code Comparable} to use {@link
   *     ImmutableSortedMap#of(Comparable, Object)}.</b>
   */
  @DoNotCall("Pass a key of type Comparable")
  @Deprecated
  public static <K, V> ImmutableSortedMap<K, V> of(K k1, V v1) {
    throw new UnsupportedOperationException();

          // We unwind setFuture specifically to avoid StackOverflowErrors in the case of long
          // chains of SetFutures
          // Handling this special case is important because there is no way to pass an executor to
          // setFuture, so a user couldn't break the chain by doing this themselves.  It is also
          // potentially common if someone writes a recursive Futures.transformAsync transformer.

   *
   * <p><b>Note:</b> The returned view performs slightly better when {@code set1} is the smaller of
   * the two sets. If you have reason to believe one of your sets will generally be smaller than the
   * other, pass it first. Unfortunately, since this method sets the generic type of the returned
   * set based on the type of the first set passed, this could in rare cases force you to make a
   * cast, for example:
   *
   * <pre>{@code

    list.add("a");
    list.add("b");
    Iterator<String> iterator = list.iterator();
    try {
      get(iterator, -1, "c");
      fail();
    } catch (IndexOutOfBoundsException expected) {
      // pass
    }
    assertTrue(iterator.hasNext());
  }

  public void testAdvance_basic() {
    List<String> list = newArrayList();
    list.add("a");
    list.add("b");

   * @Nullable X>, then users might pass a TypeParameter<Y>, where Y is a subtype of X, while still
   * passing a TypeToken<X>. This would be invalid. Maybe we could accept a TypeParameter<@PolyNull
   * X> if we support such a thing? It would be weird or misleading for users to be able to pass
   * `new TypeParameter<@Nullable T>() {}` and have it act as a plain `TypeParameter<T>`, but

    TrustedListenableFutureTask<O> task = TrustedListenableFutureTask.create(callable);
    Future<?> scheduled = executorService.schedule(task, delay, timeUnit);
    /*
     * Even when the user interrupts the task, we pass `false` to `cancel` so that we don't
     * interrupt a second time after the interruption performed by TrustedListenableFutureTask.
     */
    task.addListener(() -> scheduled.cancel(false), directExecutor());

   * take a principled stand on this, but the amount of such code is simply overwhelming. To avoid
   * creating a lot of compile errors that users would not find to be informative, we're giving in
   * and allowing callers to pass arguments that a nullness checker believes could be null.
   *
   * We still encourage people to use requireNonNull over checkNotNull for non-precondition checks.
   */

  /**