}

    // All of the seed values should have been visible, so we should have gotten removal
    // notifications for all of them.
    for (int i = 0; i < nSeededEntries; i++) {
      assertEquals("b" + i, removalNotifications.get("b" + i));
    }

    // Each of the values added to the map should either still be there, or have seen a removal
    // notification.

TODO
----

 * Add maven goal to avoid manual call to git submodule init.
 * Make hpack-test-case update itself from git, and run new tests.
 * Add maven goal to generate stories and a pull request to hpack-test-case
   to have others validate our output.

    }
  }

  override fun loadForRequest(url: HttpUrl): List<Cookie> {
    val cookieHeaders =
      try {
        // The RI passes all headers. We don't have 'em, so we don't pass 'em!
        cookieHandler.get(url.toUri(), emptyMap<String, List<String>>())
      } catch (e: IOException) {
        Platform.get().log("Loading cookies failed for " + url.resolve("/...")!!, WARN, e)

  }

  private void assertBad(String spec) {
    try {
      HostSpecifier.fromValid(spec);
      fail("Should have thrown IllegalArgumentException: " + spec);
    } catch (IllegalArgumentException expected) {
    }

    try {
      HostSpecifier.from(spec);
      fail("Should have thrown ParseException: " + spec);
    } catch (ParseException expected) {

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 *       String}.
 *   <li>{@code getElement} on a {@code Multiset.Entry<@Nullable String>} returns {@code @Nullable
 *       String}.
 * </ul>
 *
 * This is the same behavior as type-variable usages have to Kotlin and to the Checker Framework.
 * Contrast the method above to:
 *
 * <ul>
 *   <li>methods whose return type is a type variable but which can never return {@code null},

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *

   *     sequential order as produced by the iterator for the given task list. If the operation did
   *     not time out, each task will have completed. If it did time out, some of these tasks will
   *     not have completed.
   * @throws RejectedExecutionException {@inheritDoc}
   * @throws NullPointerException if any task is null
   */
  @Override