@Override
          public byte[] hash(byte[] input, int seed) {
            return murmur3_32(seed).hashBytes(input).asBytes();
          }
        };
    // Murmur3A, MurmurHash3 for x86, 32-bit (MurmurHash3_x86_32)
    // https://github.com/aappleby/smhasher/blob/master/src/main.cpp
    HashTestUtils.verifyHashFunction(hf, 32, 0xB0F57EE3);
  }

  public void testParanoid() {
    HashFn hf =

   * href="https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp">32-bit murmur3
   * algorithm, x86 variant</a> (little-endian variant), using the given seed value, <b>with a known
   * bug</b> as described in the deprecation text.
   *
   * <p>The C++ equivalent is the MurmurHash3_x86_32 function (Murmur3A), which however does not
   * have the bug.
   *

       * crashes on Android when running in 32-bit mode. For maximum safety, we shouldn't use
       * Unsafe.getLong() at all, but the performance benefit on x86_64 is too great to ignore, so
       * as a compromise, we enable the optimization only on platforms that we specifically know to
       * work.
       *

    public T get() {
      // Another variant of Double Checked Locking.
      //
      // We use two volatile reads. We could reduce this to one by
      // putting our fields into a holder class, but (at least on x86)
      // the extra memory consumption and indirection are more
      // expensive than the extra volatile reads.
      long nanos = expirationNanos;
      long now = System.nanoTime();

       *
       * In UnsignedBytesBenchmark, accessing the following objects via static final fields is the
       * fastest (more than twice as fast as the Java implementation, vs ~1.5x with non-final static
       * fields, on x86_32) under the Hotspot server compiler. The reason is obviously that the
       * non-final fields need to be reloaded inside the loop.
       *

          @Override
          public byte[] hash(byte[] input, int seed) {
            return murmur3_32(seed).hashBytes(input).asBytes();
          }
        };
    // Murmur3A, MurmurHash3 for x86, 32-bit (MurmurHash3_x86_32)
    // https://github.com/aappleby/smhasher/blob/master/src/main.cpp
    HashTestUtils.verifyHashFunction(hf, 32, 0xB0F57EE3);
  }

  public void testParanoid() {
    HashFn hf =

    X69,
    X70,
    X71,
    X72,
    X73,
    X74,
    X75,
    X76,
    X77,
    X78,
    X79,
    X80,
    X81,
    X82,
    X83,
    X84,
    X85,
    X86,
    X87,
    X88,
    X89,
    X90,
    X91,
    X92,
    X93,
    X94,
    X95,
    X96,
    X97,
    X98,
    X99
  }

  private enum LargeEnum {
    X0,

    X69,
    X70,
    X71,
    X72,
    X73,
    X74,
    X75,
    X76,
    X77,
    X78,
    X79,
    X80,
    X81,
    X82,
    X83,
    X84,
    X85,
    X86,
    X87,
    X88,
    X89,
    X90,
    X91,
    X92,
    X93,
    X94,
    X95,
    X96,
    X97,
    X98,
    X99
  }

  private enum LargeEnum {
    X0,

import java.io.Serializable;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.nio.charset.Charset;
import javax.annotation.CheckForNull;

/**
 * See MurmurHash3_x86_32 in <a
 * href="https://github.com/aappleby/smhasher/blob/master/src/MurmurHash3.cpp">the C++
 * implementation</a>.
 *
 * @author Austin Appleby
 * @author Dimitris Andreou
 * @author Kurt Alfred Kluever
 */

    public T get() {
      // Another variant of Double Checked Locking.
      //
      // We use two volatile reads. We could reduce this to one by
      // putting our fields into a holder class, but (at least on x86)
      // the extra memory consumption and indirection are more
      // expensive than the extra volatile reads.
      long nanos = expirationNanos;
      long now = System.nanoTime();