# To verify the change, run the build with:
# @bot-gradle test ReadyForNightly
# ```
# stopGradleDaemons=true
# ```
version: "v1"
jdks:
  - params:
      - "linux.java8.openjdk.64bit"
      - "linux.java8.oracle.64bit"
    os: "linux"
    arch: "amd64"
    vendor: "oracle"
    version: "8u401"
    sha256: "19684fccd7ff32a8400e952a643f0049449a772ef63b8037d5b917cbd137d173"
  - params:
      - "linux.java11.openjdk.64bit"

      - name: 'Check out repository'
        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
      # When we specify multiple JDKs, the final one becomes the default, which is used to execute Maven itself.
      # Our Maven configuration then specifies different JDKs to use for some of the steps:

    if (enableValidation) {
      compileKotlinTask.source(file("src/main/java9"))
    }

    // 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(

  openjdklatest:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Configure JDKs
        uses: actions/setup-java@v5
        with:
          distribution: 'temurin'
          java-version: |
            11
            17
            24

      - name: Allow incompatible JVM versions

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.

  // 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>