* of a call to {@code remove()}. Thus, the expectation doesn't hold that {@code map.remove(x)}
   * returns the same value which {@code map.get(x)} did immediately beforehand.
   */
  @Override
  public void testRemove() {
    final Map<String, Collection<Integer>> map;
    final String keyToRemove;
    try {
      map = makePopulatedMap();

  }

  @Override
  public void testNulls() throws Exception {
    try {
      super.testNulls();
    } catch (AssertionFailedError e) {
      assertWithMessage("Method did not throw null pointer OR element not in graph exception.")
          .that(e)
          .hasCauseThat()
          .hasMessageThat()
          .contains(ERROR_ELEMENT_NOT_IN_GRAPH);
    }
  }

        demonstrating the bug.
      render: java
    validations:
      required: true

  - type: textarea
    attributes:
      label: Expected Behavior
      description: What did you expect to happen?
    validations:
      required: true

  - type: textarea
    attributes:
      label: Actual Behavior
      description: What actually happened?
    validations:
      required: true

   * of a call to {@code remove()}. Thus, the expectation doesn't hold that {@code map.remove(x)}
   * returns the same value which {@code map.get(x)} did immediately beforehand.
   */
  @Override
  public void testRemove() {
    final Map<String, Collection<Integer>> map;
    final String keyToRemove;
    try {
      map = makePopulatedMap();

      }
      String error = errorMessage.get();
      assertNull(error, error);
    }
    executor.shutdown();
  }

  /**
   * He did the bash, he did the future bash The future bash, it was a concurrency smash He did the
   * bash, it caught on in a flash He did the bash, he did the future bash
   */

  public void testFutureBash() {
    if (isWindows()) {

    attributes:
      label: Desired Behavior
      description: What do you want it to do instead?
    validations:
      required: true

  - type: markdown
    attributes:
      value: >
        Did you *actually* encounter the need for this enhancement in a real-world scenario, or does
        it just seem like a sensible behavior for the feature to have?

    bus.post(EVENT);
    List<String> expectedEvents = ImmutableList.of(EVENT);
    for (StringCatcher catcher : catchers) {
      assertEquals(
          "One of the registered catchers did not receive an event.",
          expectedEvents,
          catcher.getEvents());
    }
  }

  public void testToString() throws Exception {
    EventBus eventBus = new EventBus("a b ; - \" < > / \\ €");

    bus.post(EVENT);
    List<String> expectedEvents = ImmutableList.of(EVENT);
    for (StringCatcher catcher : catchers) {
      assertEquals(
          "One of the registered catchers did not receive an event.",
          expectedEvents,
          catcher.getEvents());
    }
  }

  public void testToString() throws Exception {
    EventBus eventBus = new EventBus("a b ; - \" < > / \\ €");

    assertEquals("2", iterator.next());
    assertEquals("3", iterator.next());
    assertEquals("4", iterator.next());
    assertEquals(4, iterator.nextIndex());
    try {
      iterator.next();
      fail("did not detect end of list");
    } catch (NoSuchElementException expected) {
    }
    assertEquals(3, iterator.previousIndex());
    assertEquals("4", iterator.previous());
    assertEquals("3", iterator.previous());

    return makeHash();
  }

  /**
   * Computes a hash code based on the data that have been provided to this hasher. This is called
   * after all chunks are handled with {@link #process} and any leftover bytes that did not make a
   * complete chunk are handled with {@link #processRemaining}.
   */
  protected abstract HashCode makeHash();

  // Process pent-up data in chunks
  private void munchIfFull() {