* 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

    eventSource: EventSource,
    response: Response,
  ) {
  }

  /**
   * Invoked when a new event has been sent to the client.
   *
   * @param id The `id` line of the event, might be null.
   * @param type The `event` line of the event, might be null.
   * @param data The `data` line of the event.
   */
  open fun onEvent(
    eventSource: EventSource,
    id: String?,
    type: String?,
    data: String,
  ) {
  }

I say--that's the same thing, you know.'

  `Not the same thing a bit!' said the Hatter.  `You might just
as well say that "I see what I eat" is the same thing as "I eat
what I see"!'

  `You might just as well say,' added the March Hare, `that "I
like what I get" is the same thing as "I get what I like"!'

  `You might just as well say,' added the Dormouse, who seemed to

 */
/*
 * A nullable bound would let users create a TypeParameter instance for a parameter with a nullable
 * bound. However, it would also let them create `new TypeParameter<@Nullable T>() {}`, which
 * wouldn't behave as users might expect. Additionally, it's not clear how the TypeToken API could
 * support even a "normal" `TypeParameter<T>` when `<T>` has a nullable bound. (See the discussion

    }
    assertNull(
        "The array element immediately following the end of the collection should be nulled",
        array[getNumElements()]);
    // array[getNumElements() + 1] might or might not have been nulled
  }

  @CollectionFeature.Require(KNOWN_ORDER)
  public void testToArray_oversizedArray_ordered() {
    E[] array = getSubjectGenerator().createArray(getNumElements() + 2);

   * be declared as a {@code List}.
   *
   * <p>Note also that serialization is not in general required to return an object that is
   * {@linkplain Object#equals equal} to the original, nor is it required to return even an object
   * of the same class. For example, if sublists of {@code MyList} instances were serializable,

   * code would be responsible for populating a "real" {@code T} (which might still be the value
   * {@code null}!) before returning it to callers. Depending on how the code is structured, a
   * nullness analysis might not understand that the field has been populated. To avoid that problem
   * without having to add {@code @SuppressWarnings}, the code can call this method.
   *

 */
/*
 * A nullable bound would let users create a TypeParameter instance for a parameter with a nullable
 * bound. However, it would also let them create `new TypeParameter<@Nullable T>() {}`, which
 * wouldn't behave as users might expect. Additionally, it's not clear how the TypeToken API could
 * support even a "normal" `TypeParameter<T>` when `<T>` has a nullable bound. (See the discussion

    if (supportsRemove) {
      // We use a copy of "entryToRemove" in the assertion because "entryToRemove" might be
      // invalidated and have undefined behavior after entrySet.removeAll(entriesToRemove),
      // for example entryToRemove.getValue() might be null.
      Entry<K, V> entryToRemoveCopy = mapEntry(entryToRemove.getKey(), entryToRemove.getValue());

      int initialSize = map.size();

        assertNotNull(toString);
        assertTrue("toString should contain TimeZone ID", toString.contains(FessUserTimeZoneProcessProvider.centralTimeZone.getID()));
        // The provider's toString might not contain the exact class name
        // Just verify it's not null and contains some meaningful info
        assertTrue("toString should not be empty", toString.length() > 0);
    }