*/

  @Override
  public void write(char[] cbuf, int off, int len) throws IOException {
    checkNotClosed();
    // It turns out that creating a new String is usually as fast, or faster
    // than wrapping cbuf in a light-weight CharSequence.
    target.append(new String(cbuf, off, len));
  }

  /*
   * Override a few functions for performance reasons to avoid creating unnecessary strings.
   */

  @Override

 * comparator utilities, see either {@code Comparator} itself (for Java 8+), or {@code
 * com.google.common.collect.Ordering} (otherwise).
 *
 * <h3>Relationship to {@code Ordering}</h3>
 *
 * <p>In light of the significant enhancements to {@code Comparator} in Java 8, the overwhelming
 * majority of usages of {@code Ordering} can be written using only built-in JDK APIs. This class is

 * comparator utilities, see either {@code Comparator} itself (for Java 8+), or {@code
 * com.google.common.collect.Ordering} (otherwise).
 *
 * <h3>Relationship to {@code Ordering}</h3>
 *
 * <p>In light of the significant enhancements to {@code Comparator} in Java 8, the overwhelming
 * majority of usages of {@code Ordering} can be written using only built-in JDK APIs. This class is

 * randomly ordered data (the probability decreases faster than exponentially in N), but if you are
 * passing in unsanitized user data then a malicious user could force it. A light shuffle of the
 * data using an unpredictable seed should normally be enough to thwart this attack.
 *
 * <p>The time taken to compute multiple quantiles on the same dataset using {@link Scale#indexes

 * annotated with LargeTest.
 *
 * <p>Why use a custom annotation instead of {@code android.test.suitebuilder.annotation.Suppress}?
 * I'm not completely sure that this is the right choice, but it has various advantages:
 *
 * <ul>
 *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
 *       suppression. This would follow the precedent of many of our annotation processors, which

          return classify(Ints.compare(left, right));
        }

        @Override
        public ComparisonChain compare(long left, long right) {
          return classify(Longs.compare(left, right));
        }

        @Override
        public ComparisonChain compare(float left, float right) {
          return classify(Float.compare(left, right));
        }

        @Override

      successor(pred(), succ());
      if (left == null) {
        return right;
      } else if (right == null) {
        return left;
      } else if (left.height >= right.height) {
        AvlNode<E> newTop = pred();
        // newTop is the maximum node in my left subtree
        newTop.left = left.removeMax(newTop);
        newTop.right = right;
        newTop.distinctElements = distinctElements - 1;

     * 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
     * requireNonNull checks below). Plus, we're *already* lying here, since newHeader passes a null
     * key and value, which we pass to the superconstructor, even though the key and value type for

@SuppressWarnings({"unchecked", "rawtypes"}) // TODO(kevinb): the right way to explain this??
@ElementTypesAreNonnullByDefault
final class ReverseNaturalOrdering extends Ordering<Comparable<?>> implements Serializable {
  static final ReverseNaturalOrdering INSTANCE = new ReverseNaturalOrdering();

  @Override
  public int compare(Comparable<?> left, Comparable<?> right) {
    checkNotNull(left); // right null is caught later
    if (left == right) {

          accum = collector.combiner().apply(accum, newAccum);
        }
        return accum;
      }
    },
    /** Get one accumulator for each element and merge the accumulators right-to-left. */
    MERGE_RIGHT_ASSOCIATIVE {
      @Override
      final <T extends @Nullable Object, A extends @Nullable Object, R extends @Nullable Object>
          A result(Collector<T, A, R> collector, Iterable<T> inputs) {