* `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple
   * `Integer.valueOf` calls into one! So we stick with the deprecated `Integer` constructor.
   */

     * to avoid the extra class for the lambda (and maybe more for memoizingSupplier itself) and the
     * indirection.
     *
     * One thing to *avoid* is a change to make each Logger user use memoizingSupplier directly:
     * That may introduce an extra class for each lambda (currently a dozen).
     */
    Logger local = logger;
    if (local != null) {

     * Wait for the interrupting thread to set DONE. (See interruptTask().) We want to wait so that
     * the interrupting thread doesn't interrupt the _next_ thing to run on this thread.
     *
     * Note: We don't reset the interrupted bit, just wait for it to be set. If this is a thread
     * pool thread, the thread pool will reset it for us. Otherwise, the interrupted bit may have

    if ((!features.contains(IteratorFeature.SUPPORTS_REMOVE) && removes > 1)
        || (stimuli.length >= 5 && removes > 2)) {
      // removes are the most expensive thing to test, since they often throw exceptions with stack
      // traces, so we test them a bit less aggressively
      return;
    }

   * `new Integer` (as we do) instead of `Integer.valueOf`. However, under J2KT, `new Integer`
   * gets translated back to `Integer.valueOf` because that is the only thing J2KT can support. And
   * anyway, it's nice to avoid `Integer.valueOf` because the Android toolchain optimizes multiple
   * `Integer.valueOf` calls into one! So we stick with the deprecated `Integer` constructor.
   */

    if ((!features.contains(IteratorFeature.SUPPORTS_REMOVE) && removes > 1)
        || (stimuli.length >= 5 && removes > 2)) {
      // removes are the most expensive thing to test, since they often throw exceptions with stack
      // traces, so we test them a bit less aggressively
      return;
    }

            + " and-another-thing=\"\"; normal-thing=foo",
        MediaType.create("text", "plain")
            .withParameter("something", "cr@zy")
            .withParameter("something-else", "crazy with spaces")
            .withParameter("and-another-thing", "")
            .withParameter("normal-thing", "foo")
            .toString());
  }

            + " and-another-thing=\"\"; normal-thing=foo",
        MediaType.create("text", "plain")
            .withParameter("something", "cr@zy")
            .withParameter("something-else", "crazy with spaces")
            .withParameter("and-another-thing", "")
            .withParameter("normal-thing", "foo")
            .toString());
  }

  //
  // 1. What about leaving/unlocking? Are you going to do
  //    guard.enter() paired with monitor.leave()? That might get
  //    confusing. It's nice for the finally block to look as close as
  //    possible to the thing right before the try. You could have
  //    guard.leave(), but that's a little odd as well because the
  //    guard doesn't have anything to do with leaving. You can't

    }
    return offset;
  }

  @J2ktIncompatible // serialization
  @GwtIncompatible // serialization
  Object writeReplace() {
    // We serialize by default to ImmutableList, the simplest thing that works.
    return new ImmutableList.SerializedForm(toArray());
  }

  @J2ktIncompatible // serialization
  private void readObject(ObjectInputStream stream) throws InvalidObjectException {