*   <li>have equal funnels
   * </ul>
   *
   * @param that The Bloom filter to check for compatibility.
   * @since 15.0
   */
  public boolean isCompatible(BloomFilter<T> that) {
    checkNotNull(that);
    return this != that
        && this.numHashFunctions == that.numHashFunctions
        && this.bitSize() == that.bitSize()
        && this.strategy.equals(that.strategy)
        && this.funnel.equals(that.funnel);
  }

/**
 * A set of worker threads that are shared among a set of task queues.
 *
 * Use [INSTANCE] for a task runner that uses daemon threads. There is not currently a shared
 * instance for non-daemon threads.
 *
 * The task runner is also responsible for releasing held threads when the library is unloaded.
 * This is for the benefit of container environments that implement code unloading.
 *

          <sourcepath>doesnotexist</sourcepath>
          <!-- Note that we do need to build Javadoc for *some* class. Otherwise, we get an empty Javadoc jar, which the Sonatype repository manager rejects. To avoid that, we've introduced a dummy class. But we made it package-private so that no one can depend on it. That in turn forced us to configure Javadoc to show package-private APIs. -->
          <show>package</show>

      }
      iterations++;
      if (iterations >= maxIterations) {
        @SuppressWarnings("nullness") // safe because we pass sort() a range that contains real Ts
        T[] castBuffer = (T[]) buffer;
        // We've already taken O(k log k), let's make sure we don't take longer than O(k log k).
        sort(castBuffer, left, right + 1, comparator);
        break;
      }
    }
    bufferSize = k;

         * _different bounds_ than the JDK TypeVariable. And it wouldn't make sense for our new
         * TypeVariable to be equal to any _other_ JDK TypeVariable, either, because any other JDK
         * TypeVariable must have a different declaration or name. The only TypeVariable that our
         * new TypeVariable _will_ be equal to is an equivalent TypeVariable that was also created

         * _different bounds_ than the JDK TypeVariable. And it wouldn't make sense for our new
         * TypeVariable to be equal to any _other_ JDK TypeVariable, either, because any other JDK
         * TypeVariable must have a different declaration or name. The only TypeVariable that our
         * new TypeVariable _will_ be equal to is an equivalent TypeVariable that was also created

   * has not added {@link AnnotatedType}. That means that we cannot implement that interface in
   * source code in a way that will compile on both Java and Android. If we include the {@code
   * getAnnotatedBounds()} method, then its return type means it won't compile on Android, while if
   * we don't include the method, then the compiler will complain that an abstract method is

The `string()` method on response body is convenient and efficient for small documents. But if the response body is large (greater than 1 MiB), avoid `string()` because it will load the entire document into memory. In that case, prefer to process the body as a stream.

=== ":material-language-kotlin: Kotlin"
    ```kotlin
      private val client = OkHttpClient()

      fun run() {
        val request = Request.Builder()

   * has not added {@link AnnotatedType}. That means that we cannot implement that interface in
   * source code in a way that will compile on both Java and Android. If we include the {@code
   * getAnnotatedBounds()} method, then its return type means it won't compile on Android, while if
   * we don't include the method, then the compiler will complain that an abstract method is

    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