import java.util.concurrent.Future;
import junit.framework.TestCase;

/**
 * Basher test for {@link AtomicLongMap}.
 *
 * @author mike nonemacher
 */
@J2ktIncompatible // threads
@GwtIncompatible // threads
public class AtomicLongMapBasherTest extends TestCase {
  private final Random random = new Random(301);

  public void testModify_basher() throws Exception {
    int nTasks = 3000;
    int nThreads = 100;

  }

  static HashCode randomHash(HashFunction hashFunction, Random random, int numActions) {
    Hasher hasher = hashFunction.newHasher();
    for (int i = 0; i < numActions; i++) {
      RandomHasherAction.pickAtRandom(random).performAction(random, ImmutableSet.of(hasher));
    }
    return hasher.hash();
  }

  private static void assertShortcutsAreEquivalent(HashFunction hashFunction, int trials) {

      for (String algorithmToTest : ALGORITHMS.keySet()) {
        assertMessageDigestHashing(HashTestUtils.ascii(stringToTest), algorithmToTest);
      }
    }
  }

  public void testPutAfterHash() {
    Hasher sha1 = Hashing.sha1().newHasher();

    assertEquals(
        "2fd4e1c67a2d28fced849ee1bb76e7391b93eb12",
        sha1.putString("The quick brown fox jumps over the lazy dog", Charsets.UTF_8)
            .hash()

 * Otherwise, at least reduce <i>explicit</i> dependencies on this type by using lambda expressions
 * or method references instead of classes, leaving your code easier to migrate in the future.
 *
 * <p>See the Guava User Guide article on <a
 * href="https://github.com/google/guava/wiki/FunctionalExplained">the use of {@code Function}</a>.
 *
 * @author Kevin Bourrillion
 * @since 2.0

          CharStreams.copy(reader, sb);
        }
        return sb.toString();
      }
    },
    // It really seems like this should be faster than TO_BYTE_ARRAY_NEW_STRING.  But it just isn't
    // my best guess is that the jdk authors have spent more time optimizing that callpath than this

          CharStreams.copy(reader, sb);
        }
        return sb.toString();
      }
    },
    // It really seems like this should be faster than TO_BYTE_ARRAY_NEW_STRING.  But it just isn't
    // my best guess is that the jdk authors have spent more time optimizing that callpath than this

    b *= mul;
    return b;
  }

  /**
   * Computes intermediate hash of 32 bytes of byte array from the given offset. Results are
   * returned in the output array because when we last measured, this was 12% faster than allocating
   * new arrays every time.
   */
  private static void weakHashLength32WithSeeds(
      byte[] bytes, int offset, long seedA, long seedB, long[] output) {
    long part1 = load64(bytes, offset);

   * <p>Many of the filtered map's methods, such as {@code size()}, iterate across every key/value
   * mapping in the underlying map and determine which satisfy the filter. When a live view is
   * <i>not</i> needed, it may be faster to copy the filtered map and use the copy.
   *
   * <p><b>Warning:</b> {@code keyPredicate} must be <i>consistent with equals</i>, as documented at
   * {@link Predicate#apply}. Do not provide a predicate such as {@code

@ElementTypesAreNonnullByDefault
enum BloomFilterStrategies implements BloomFilter.Strategy {
  /**
   * See "Less Hashing, Same Performance: Building a Better Bloom Filter" by Adam Kirsch and Michael
   * Mitzenmacher. The paper argues that this trick doesn't significantly deteriorate the
   * performance of a Bloom filter (yet only needs two 32bit hash functions).
   */
  MURMUR128_MITZ_32() {
    @Override

   * {@link #ignoreClasses} to exclude generated classes, such as the {@code AutoValue_Foo} classes
   * generated by <a href="https://github.com/google/auto/tree/master/value">AutoValue</a>.
   *
   * @since 19.0
   */
  public static final Predicate<Class<?>> UNDERSCORE_IN_NAME =
      (Class<?> c) -> c.getSimpleName().contains("_");