should not use them for communication between trusted and untrusted code.

6.  For the mainline flavor, we test the libraries using OpenJDK 8, 11, and 17
    on Linux, with some additional testing on newer JDKs and on Windows. Some
    features, especially in `com.google.common.io`, may not work correctly in
    non-Linux environments. For the Android flavor, our unit tests also run on
    API level 23 (Marshmallow).

Available JDKs on your machine are automatically detected and wired for the various compile and test tasks.
Some tests require multiple JDKs to be installed on your computer, be aware of this if you make changes related to anything toolchains related.

        Class<?> optionalClass = Class.forName("java.util.Optional");
        /*
         * We don't *need* to use reflection to access Optional: It's available on all JDKs we
         * support, and Android code won't get this far, anyway, because ProcessHandle is
         * unavailable. But given how much other reflection we're using, we might as well use it

  // Set the Java release version.
  options.release.set(9)

  // Ignore warnings about using 'requires transitive' on automatic modules.
  // not needed when compiling with recent JDKs, e.g. 17
  options.compilerArgs.add("-Xlint:-requires-transitive-automatic")

  // Patch the compileKotlinJvm output classes into the compilation so exporting packages works correctly.
  options.compilerArgs.addAll(

   * of Java 20, it always throws an exception, and as of Java 26, the method does not even exist.
   * For now, we continue using it to clean up under older JDKs.
   *
   * Our usages should at least be *relatively* safe: Typically, threads started by a test are dying
   * at the end of the test, so there is no object state put at risk by stopping the threads

   * of Java 20, it always throws an exception, and as of Java 26, the method does not even exist.
   * For now, we continue using it to clean up under older JDKs.
   *
   * Our usages should at least be *relatively* safe: Typically, threads started by a test are dying
   * at the end of the test, so there is no object state put at risk by stopping the threads

         * aren't stripping UnsafeComparator today? Should we have Proguard configuration for it?)
         *
         * - if Unsafe is removed entirely from JDKs (or already absent in some unusual environment
         * today). TODO: b/392974826 - Check for the existence of Unsafe and its methods
         * reflectively before attempting to access UnsafeComparator. Or, better yet, allow

            <!--
            We can apparently have only one <jdk> per execution: Others are silently ignored :(
            To properly test this, you need to remove existing toolchains:
            rm -rf ~/.m2/jdks/ ~/.m2/toolchains.xml
            (But don't run that if you have put something into ~/.m2/toolchains.xml yourself.)
            -->
            <execution>
              <id>download-25-and-surefire-version</id>

   *       <ul>
   *         <li>UNSET, meaning "null pointer"
   *         <li>one plus an index into the entries and elements array
   *       </ul>
   *   <li>another java.util.Set delegate implementation. In most modern JDKs, normal java.util hash
   *       collections intelligently fall back to a binary search tree if hash table collisions are
   *       detected. Rather than going to all the trouble of reimplementing this ourselves, we

   *       <ul>
   *         <li>UNSET, meaning "null pointer"
   *         <li>one plus an index into the entries and elements array
   *       </ul>
   *   <li>another java.util.Set delegate implementation. In most modern JDKs, normal java.util hash
   *       collections intelligently fall back to a binary search tree if hash table collisions are
   *       detected. Rather than going to all the trouble of reimplementing this ourselves, we