* escaper escapes all non-ASCII characters, even though <a
   * href="https://url.spec.whatwg.org/#url-code-points">many of these are accepted in modern
   * URLs</a>. (<a href="https://url.spec.whatwg.org/#path-state">If the escaper were to leave these
   * characters unescaped, they would be escaped by the consumer at parse time, anyway.</a>)

 *  New: APIs to prevent retrying non-idempotent requests.
 *  Fix: Drop NPN support. Going forward we support ALPN only.
 *  Fix: The hostname verifier is now strict. This is consistent with the hostname
    verifier in modern browsers.
 *  Fix: Improve `CONNECT` handling for misbehaving HTTP proxies.
 *  Fix: Don't retry requests that failed due to timeouts.
 *  Fix: Cache 302s and 308s that include appropriate response headers.

     * that trigger this are HEADERS and PUSH_PROMISE.
     *
     * @param inFinished true if the sender will not send further frames.
     * @param streamId the stream owning these headers.
     * @param associatedStreamId the stream that triggered the sender to create this stream.
     */
    fun headers(
      inFinished: Boolean,
      streamId: Int,
      associatedStreamId: Int,

    //    second thread can then dispatch to the subscriber it took before the first thread does.
    //
    // All this makes me really wonder if there's any value in queueing here at all. A dispatcher
    // that simply loops through the subscribers and dispatches the event to each would actually

   * escaper escapes all non-ASCII characters, even though <a
   * href="https://url.spec.whatwg.org/#url-code-points">many of these are accepted in modern
   * URLs</a>. (<a href="https://url.spec.whatwg.org/#path-state">If the escaper were to leave these
   * characters unescaped, they would be escaped by the consumer at parse time, anyway.</a>)

            // Expected
        }

        // Test with single number
        System.setProperty("java.version", "17");
        assertEquals(17, JvmUtil.getJavaVersion());

        // Test with modern versions
        System.setProperty("java.version", "21.0.1");
        assertEquals(21, JvmUtil.getJavaVersion());

        // Test with early access versions (should fail with NumberFormatException)

      }

      HTTP_CLIENT_TIMEOUT -> {
        // 408's are rare in practice, but some servers like HAProxy use this response code. The
        // spec says that we may repeat the request without modifications. Modern browsers also
        // repeat the request (even non-idempotent ones.)
        if (!client.retryOnConnectionFailure) {
          // The application layer has directed us not to retry the request.
          return null

        .cipherSuites(*RESTRICTED_CIPHER_SUITES.toTypedArray())
        .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
        .supportsTlsExtensions(true)
        .build()

    /**
     * A modern TLS configuration that works on most client platforms and can connect to most servers.
     * This is OkHttp's default configuration.
     */
    @JvmField
    val MODERN_TLS =
      Builder(true)

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

       * AGP: https://github.com/google/guava/issues/7769.
       *
       * My impression is that an AtomicReferenceFieldUpdater in a static field is similarly fast to
       * Unsafe on modern JVMs (if perhaps not quite as fast as VarHandle?). However, I'm not sure
       * exactly what we've benchmarked, and we certainly haven't benchmarked as far back as JDK 8.