* type. That said, we could *accept* a `@Nullable T[]` (which, given that we treat arrays as
   * covariant, would still permit a plain `T[]`) and return a plain `T[]`. But of course that would
   * require its own suppression, since it is also unsound. toArray(T[]) is just a mess from a

        .addEqualityGroup(
            MediaType.create("text", "plain"),
            MediaType.create("TEXT", "PLAIN"),
            MediaType.parse("text/plain"),
            MediaType.parse("TEXT/PLAIN"),
            MediaType.parse("text /plain"),
            MediaType.parse("TEXT/ plain"),
            MediaType.parse("text / plain"),
            MediaType.create("text", "plain").withParameter("a", "1").withoutParameters())

   * returns. This method may be useful when testing the garbage collection mechanism itself, or
   * inhibiting a spontaneous GC initiation in subsequent code.
   *
   * <p>In contrast, a plain call to {@link java.lang.System#gc()} does not ensure finalization
   * processing and may run concurrently, for example, if the JVM flag {@code
   * -XX:+ExplicitGCInvokesConcurrent} is used.
   *

       *
       * (And I don't believe there's any situation in which we call x.combine(y) when x is a plain
       * ImmutableSet.Builder but y is an ImmutableSortedSet.Builder (or vice versa). Certainly
       * ImmutableSortedSet.Builder.combine() is written as if its argument will never be a plain
       * ImmutableSet.Builder: It casts immediately to ImmutableSortedSet.Builder.)
       */
      copyIfNecessary();

     *
     * 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
     * inputs, rather than as if it never tolerates them.
     *

    }
  }

  /**
   * Returns a {@link Collection} of all the permutations of the specified {@link Collection}.
   *
   * <p><i>Notes:</i> This is an implementation of the Plain Changes algorithm for permutations
   * generation, described in Knuth's "The Art of Computer Programming", Volume 4, Chapter 7,
   * Section 7.2.1.2.
   *

 * Benchmarks (as of December 2011) show that:
 *
 * <ul>
 *   <li>for an unnested {@code lock()} and {@code unlock()}, a cycle detecting lock takes 38ns as
 *       opposed to the 24ns taken by a plain lock.
 *   <li>for nested locking, the cost increases with the depth of the nesting:
 *       <ul>
 *         <li>2 levels: average of 64ns per lock()/unlock()
 *         <li>3 levels: average of 77ns per lock()/unlock()

  }

  /*
   * Tests that we workaround GWT bug #3621 (or that it is already fixed).
   *
   * A call to of() with a parameter that is not a plain Object[] (here,
   * Interface[]) creates a RegularImmutableSortedSet backed by an array of that
   * type. Later, RegularImmutableSortedSet.toArray() calls System.arraycopy()

        .addEqualityGroup(
            MediaType.create("text", "plain"),
            MediaType.create("TEXT", "PLAIN"),
            MediaType.parse("text/plain"),
            MediaType.parse("TEXT/PLAIN"),
            MediaType.parse("text /plain"),
            MediaType.parse("TEXT/ plain"),
            MediaType.parse("text / plain"),
            MediaType.create("text", "plain").withParameter("a", "1").withoutParameters())

         * However, we don't expose currentFuture to users, so they can't attach listeners. And the
         * Future might not even be a ListenableFuture, just a plain Future. That said, similar
         * problems can exist with methods like FutureTask.done(), not to mention slow calls to
         * Thread.interrupt() (as discussed in InterruptibleTask). At the end of the day, it's