* on its instance of {@code TypeVariableImpl}. Otherwise it throws {@link
   * UnsupportedOperationException}; this should only apply to {@code getAnnotatedBounds()}. This
   * does mean that users on Java 8 who obtain an instance of {@code TypeVariable} from {@link
   * TypeResolver#resolveType} will not be able to call {@code getAnnotatedBounds()} on it, but that
   * should hopefully be rare.
   *

 * <ul>
 *   <li><a href="https://dagger.dev/producers.html">Dagger Producers</a>
 * </ul>
 *
 * <h4>{@link java.util.concurrent.CompletableFuture} / {@link java.util.concurrent.CompletionStage}
 * </h4>
 *
 * <p>Users of {@code CompletableFuture} will likely want to continue using {@code
 * CompletableFuture}. {@code FluentFuture} is targeted at people who use {@code ListenableFuture},

   *     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>.
   */

import javax.annotation.CheckForNull;
import org.checkerframework.checker.nullness.qual.Nullable;

/**
 * Provides static methods for working with {@code Collection} instances.
 *
 * <p><b>Java 8+ users:</b> several common uses for this class are now more comprehensively
 * addressed by the new {@link java.util.stream.Stream} library. Read the method documentation below

         * just one problem: Starting with JDK 7u51, the JDK TypeVariable's equals() method doesn't
         * recognize instances of our TypeVariable implementation. This is a problem because users
         * compare TypeVariables from the JDK against TypeVariables returned by TypeResolver. To
         * work with all JDK versions, TypeResolver must return the appropriate TypeVariable

       * errorMessageTemplate parameters: It is unlikely that callers intend for their string
       * 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.
       */

   *
   * <ul>
   *   <li>it may split surrogate pairs
   *   <li>it may split characters and combining characters
   *   <li>it does not consider word boundaries
   *   <li>if truncating for display to users, there are other considerations that must be taken
   *       into account
   *   <li>the appropriate truncation indicator may be locale-dependent
   *   <li>it is safe to use non-ASCII characters in the truncation indicator

   * ImmutableMultiset#toImmutableMultiset}.
   *
   * @since 33.2.0 (available since 22.0 in guava-jre)
   */
  @SuppressWarnings({"AndroidJdkLibsChecker", "Java7ApiChecker"})
  @IgnoreJRERequirement // Users will use this only if they're already using streams.
  @Beta // TODO: b/288085449 - Remove.
  public static <T extends @Nullable Object, E extends @Nullable Object, M extends Multiset<E>>
      Collector<T, ?, M> toMultiset(

 * existing users, but it can't *fix* existing users because any users who needed
 * `Function<@Nullable A, @Nullable B>` already had to find a workaround. Still, there is a *ton* of
 * fallout from trying to switch. I would be shocked if the switch would offer benefits to anywhere
 * near enough users to justify the costs.
 *

 * `-android` "flavors.")
 *
 * (We could consider releasing a listenablefuture:1.0.1 someday. But we would want to look into how
 * that affects users, especially users of the Android Gradle Plugin, since the plugin developers
 * put in a special hack for us: https://issuetracker.google.com/issues/131431257)
 */