* a given entry might not include null. The right fix for the header problems is probably to
     * define a separate MultimapLink interface with a separate "header" implementation, which
     * hopefully could avoid implementing Entry or ValueSetLink at all. (But note that that approach
     * requires us to define extra classes -- unfortunate under Android.) *Then* we could consider

  }

  private long link(int i) {
    return requireLinks()[i];
  }

  private void setLink(int i, long value) {
    requireLinks()[i] = value;
  }

  /*
   * We don't define getPredecessor+getSuccessor and setPredecessor+setSuccessor here because
   * they're defined above -- including logic to add and subtract 1 to map between the values stored

  }

  @SuppressWarnings("unused") // compilation test
  public void testSampleCodeFine1() {
    Optional<Number> optionalInt = Optional.of((Number) 1);
    Number value = optionalInt.or(0.5); // fine
  }

  @SuppressWarnings("unused") // compilation test
  public void testSampleCodeFine2() {
    FluentIterable<? extends Number> numbers = getSomeNumbers();

   */

  private int[] requirePredecessors() {
    return requireNonNull(predecessor);
  }

  private int[] requireSuccessors() {
    return requireNonNull(successor);
  }

  /*
   * We don't define getPredecessor+getSuccessor and setPredecessor+setSuccessor here because
   * they're defined above -- including logic to add and subtract 1 to map between the values stored

 * @author Robert Konigsberg
 */
@GwtCompatible
@ElementTypesAreNonnullByDefault
public class UnmodifiableCollectionTests {

  public static void assertMapEntryIsUnmodifiable(Entry<?, ?> entry) {
    try {
      // fine because the call is going to fail without modifying the entry
      @SuppressWarnings("unchecked")
      Entry<?, @Nullable Object> nullableValueEntry = (Entry<?, @Nullable Object>) entry;
      nullableValueEntry.setValue(null);

   * {@code <A>} using our implementation unless some of its bounds have changed in resolution. This
   * avoids creating unequal TypeVariable implementation unnecessarily. When the bounds do change,
   * however, it's fine for the synthetic TypeVariable to be unequal to any native TypeVariable
   * anyway.
   */
  static final class NativeTypeVariableEquals<X> {
    static final boolean NATIVE_TYPE_VARIABLE_ONLY =

          // https://code.google.com/p/android/issues/detail?id=196555
          continue;
        }
        if (isAndroid && p.equals(BAD_FOR_GINGERBREAD_P) && q.equals(BAD_FOR_GINGERBREAD_Q)) {
          // Works fine under Marshmallow, so I haven't filed a bug.
          continue;
        }

        boolean dividesEvenly = p.remainder(q).equals(ZERO);

        try {

          // https://code.google.com/p/android/issues/detail?id=196555
          continue;
        }
        if (isAndroid && p.equals(BAD_FOR_GINGERBREAD_P) && q.equals(BAD_FOR_GINGERBREAD_Q)) {
          // Works fine under Marshmallow, so I haven't filed a bug.
          continue;
        }

        boolean dividesEvenly = p.remainder(q).equals(ZERO);

        try {

            + Long.numberOfLeadingZeros(~a)
            + Long.numberOfLeadingZeros(b)
            + Long.numberOfLeadingZeros(~b);
    /*
     * If leadingZeros > Long.SIZE + 1 it's definitely fine, if it's < Long.SIZE it's definitely
     * bad. We do the leadingZeros check to avoid the division below if at all possible.
     *
     * Otherwise, if b == Long.MIN_VALUE, then the only allowed values of a are 0 and 1. We take

   * appears that this pattern is not directly applicable. But we can use the ridiculous, devious
   * trick of throwing an exception in the middle of the construction of another exception. Hotspot
   * is fine with that.
   */

  /**
   * Ensures that {@code index} specifies a valid <i>element</i> in an array, list or string of size