* who can't use Java 8, or who want an API more focused than {@code CompletableFuture}. (If you
 * need to adapt between {@code CompletableFuture} and {@code ListenableFuture}, consider <a
 * href="https://github.com/lukas-krecan/future-converter">Future Converter</a>.)
 *
 * <h3>Extension</h3>
 *
 * If you want a class like {@code FluentFuture} but with extra methods, we recommend declaring your

    Some tests need reflective access to the internals of these packages. It is only the
    tests themselves and not the code being tested that needs that access, though there's no
    obvious way to ensure that.

    We could consider arranging things so that only the tests we know need this would get
    the add-opens. Right now that doesn't seem worth the effort, though.
    -->
    <test.add.opens>
      --add-opens java.base/java.lang=ALL-UNNAMED

    Some tests need reflective access to the internals of these packages. It is only the
    tests themselves and not the code being tested that needs that access, though there's no
    obvious way to ensure that.

    We could consider arranging things so that only the tests we know need this would get
    the add-opens. Right now that doesn't seem worth the effort, though.
    -->
    <test.add.opens>
      --add-opens java.base/java.lang=ALL-UNNAMED

  // * Future completion can be observed if the waitersField field contains a TOMBSTONE

  // Timed Get
  // There are a few design constraints to consider
  // * We want to be responsive to small timeouts, unpark() has non trivial latency overheads (I
  //   have observed 12 micros on 64-bit linux systems to wake up a parked thread). So if the

   * be updated after modifications to {@code graph}.
   *
   * @since 33.1.0 (present with return type {@code Graph} since 20.0)
   */
  // TODO(b/31438252): Consider potential optimizations for this algorithm.
  public static <N> ImmutableGraph<N> transitiveClosure(Graph<N> graph) {
    ImmutableGraph.Builder<N> transitiveClosure =

   */
  public static class Builder<C extends Comparable<?>> {
    private final List<Range<C>> ranges;

    public Builder() {
      this.ranges = new ArrayList<>();
    }

    // TODO(lowasser): consider adding union, in addition to add, that does allow overlap

    /**
     * Add the specified range to this builder. Adjacent ranges are permitted and will be merged,

   * stripes (much like the birthday paradox, where much fewer than anticipated birthdays are needed
   * for a pair of them to match). Please consider carefully the implications of the number of
   * stripes, the intended concurrency level, and the typical number of keys used in a {@code
   * bulkGet(keys)} operation. See <a href="http://www.mathpages.com/home/kmath199.htm">Balls in

   * be updated after modifications to {@code graph}.
   *
   * @since 33.1.0 (present with return type {@code Graph} since 20.0)
   */
  // TODO(b/31438252): Consider potential optimizations for this algorithm.
  public static <N> ImmutableGraph<N> transitiveClosure(Graph<N> graph) {
    ImmutableGraph.Builder<N> transitiveClosure =

  // * Future completion can be observed if the waitersField field contains a TOMBSTONE

  // Timed Get
  // There are a few design constraints to consider
  // * We want to be responsive to small timeouts, unpark() has non trivial latency overheads (I
  //   have observed 12 micros on 64-bit linux systems to wake up a parked thread). So if the

    /** Executor service for concurrent search operations across multiple searchers */
    protected ExecutorService executorService;

    /** Size of the window for rank fusion processing, determines how many results to consider */
    protected int windowSize;

    /** Set of available searcher names that can be used for search processing */
    protected Set<String> availableSearcherNameSet;

    /**