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

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

  private var coordinatorWakeUpAt = 0L

  /**
   * When we need a new thread to run tasks, we call [Backend.execute]. A few microseconds later we
   * expect a newly-started thread to call [Runnable.run]. We shouldn't request new threads until
   * the already-requested ones are in service, otherwise we might create more threads than we need.
   *

              [INFO] Validating units:
              [INFO]    Ignored 53 units with compilation errors in first pass.
              [INFO] Compile with -strict or with -logLevel set to TRACE or DEBUG to see all errors.

            Turning up the log level, we see that GWT is trying to compile classes from other
            packages, like RangeTest. The reason for this is that GWT doesn't distinguish between

   * range [0, k) and ignore the remaining elements.
   */
  private final @Nullable T[] buffer;
  private int bufferSize;

  /**
   * The largest of the lowest k elements we've seen so far relative to this comparator. If
   * bufferSize ≥ k, then we can ignore any elements greater than this value.
   */
  private @Nullable T threshold;

        uses: actions/setup-java@dded0888837ed1f317902acf8a20df0ad188d165 # v5.0.0
        with:
          # For discussion, see the first setup-java block.
          # The generate-docs workflow doesn't run tests, so we don't have to care which version Maven would select for that step.
          # But we need Java 11 for JDiff.
          java-version: |
            11
            24
          distribution: 'temurin'

   * {@link TypeVariableImpl#equals(Object)} is changed to no longer be equal to custom TypeVariable
   * implementations. As a result, we need to make sure our TypeVariable implementation respects
   * symmetry. Moreover, we don't want to reconstruct a native type variable {@code <A>} using our

   * matches.
   *
   * <p>On the other hand, if for example we are resolving {@code List<A extends B>} to {@code
   * List<A extends String>}, we need to compare that {@code <A extends B>} is unequal to {@code <A
   * extends String>} in order to decide to use the transformed type instead of the original type.
   */
  static final class TypeVariableKey {

          System.out.println("Vary: " + response.headers("Vary"));
        }
      }
    ```

### Posting a String ([.kt][PostStringKotlin], [.java][PostStringJava])

Use an HTTP POST to send a request body to a service. This example posts a markdown document to a web service that renders markdown as HTML. Because the entire request body is in memory simultaneously, avoid posting large (greater than 1 MiB) documents using this API.

   * {@link TypeVariableImpl#equals(Object)} is changed to no longer be equal to custom TypeVariable
   * implementations. As a result, we need to make sure our TypeVariable implementation respects
   * symmetry. Moreover, we don't want to reconstruct a native type variable {@code <A>} using our