* 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();

   * @param pattern the pattern on which to filter file names
   */
  public PatternFilenameFilter(Pattern pattern) {
    this.pattern = Preconditions.checkNotNull(pattern);
  }

  /*
   * Our implementation works fine with a null `dir`. However, there's nothing in the documentation
   * of the supertype that suggests that implementations are expected to tolerate null. That said, I

   */

  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

   *
   * Note that sometimes these fields *do* have correct values under J2CL: They will if the caller
   * calls `create(Foo.class)`, rather than `create(map)`. That's fine; we just shouldn't rely on
   * it.
   */
  transient Class<K> keyTypeOrObjectUnderJ2cl;
  transient Class<V> valueTypeOrObjectUnderJ2cl;

  /**

 * @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 {