* com.google.common.testing.junit3.TearDownTestCase} and {@code
   * com.google.common.testing.junit4.TearDownTestCase} for example.
   *
   * <p>A failing {@link TearDown} may or may not fail a tl4j test, depending on the version of
   * JUnit test case you are running under. To avoid failing in the face of an exception regardless
   * of JUnit version, implement a {@link SloppyTearDown} instead.
   *

    assertEquals(expected, SIP_WITH_KEY.hashString(input, UTF_8).asLong());
    assertEquals(expected, SIP_WITH_KEY.newHasher().putString(input, UTF_8).hash().asLong());
    assertEquals(expected, SIP_WITHOUT_KEY.hashString(input, UTF_8).asLong());
    assertEquals(expected, SIP_WITHOUT_KEY.newHasher().putString(input, UTF_8).hash().asLong());
  }

  private static void assertSip(byte[] input, long expected) {

        // ----------------------------------------------------------------------
        // Value taken from p2
        // ----------------------------------------------------------------------

        assertEquals("mailing-list", project4.getMailingLists().get(0).getName());

        // ----------------------------------------------------------------------
        // Value taken from p1

      multimap().putAll(k3(), Lists.newArrayList(null, v3()));
      fail();
    } catch (NullPointerException expected) {
    }

    /*
     * In principle, a Multimap implementation could add e3 first before failing on the null. But
     * that seems unlikely enough to be worth complicating the test over, especially if there's any
     * chance that a permissive test could mask a bug.
     */
    expectUnchanged();

  }

  @Benchmark
  boolean get(int reps) {
    // Paranoia: acting on hearsay that accessing fields might be slow
    // Should write a benchmark to test that!
    Map<Element, Element> map = mapToTest;
    Element[] queries = this.queries;

    // Allows us to use & instead of %, acting on hearsay that division
    // operators (/%) are disproportionately expensive; should test this too!

 * tries to refer to our dummy serializer for the superclass,
 * ImmutableMultiset_CustomFieldSerializer. But that type has no methods (since it's never actually
 * used). We could probably fix the problem by adding dummy methods to that class, but that is
 * starting to sound harder than taking the superclass approach, which I've been coming to like,
 * anyway, since it doesn't require us to declare dummy methods (though occasionally constructors)

 *
 * <p>The {@link #count} and {@link #size} implementations all iterate across the set returned by
 * {@link Multiset#entrySet()}, as do many methods acting on the set returned by {@link
 * #elementSet()}. Override those methods for better performance.
 *
 * @author Louis Wasserman
 */
@GwtCompatible(emulated = true)
@ElementTypesAreNonnullByDefault

            if (lastChild instanceof Text) {
                lastChild.setTextContent(lastChild.getTextContent().replaceFirst("\\s+$", ""));
            }
            valueTitles.add(element);
        }

        //adding the properties from the super class onto the inheriting class
        Map<String, PropertyDoc> props = new TreeMap<String, PropertyDoc>();
        List<ClassDoc> superTypes = classDoc.getSuperTypes();

        if (commitId.isBlank() || commitId.toLowerCase().contains("unknown")) {
            // we can't figure out the commit ID (probably this is a source distribution build), let's skip adding source links
            return;
        }

        extension.getSourceRoots().getFiles()
            .forEach(
                file -> {

 * #remove(Object, int)} to enable modifications to the multiset.
 *
 * <p>The {@link #count} and {@link #size} implementations all iterate across the set returned by
 * {@link Multiset#entrySet()}, as do many methods acting on the set returned by {@link
 * #elementSet()}. Override those methods for better performance.
 *
 * @author Kevin Bourrillion
 * @author Louis Wasserman
 */
@GwtCompatible
@ElementTypesAreNonnullByDefault