// Even though the contract in System.getProperties() specifies that a value will exist for
      // all of the listed keys, for some reason the "java.compiler" key returns null in some JVMs.
      if (property == JAVA_COMPILER) {
        continue;
      }
      // Removed in Java 9:
      // https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B

Each process, or "runtime", applies different constraints to the code that runs in that process.
For example, each process has different supported JVMs and a different set of services available for dependency injection.
While a lot of Gradle source code runs only in the Gradle daemon, not all of it does so.

      // Even though the contract in System.getProperties() specifies that a value will exist for
      // all of the listed keys, for some reason the "java.compiler" key returns null in some JVMs.
      if (property == JAVA_COMPILER) {
        continue;
      }
      // Removed in Java 9:
      // https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-2C896CA8-927C-4381-A737-B1D81D964B7B

       * 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.
       * (We also haven't benchmarked under Android. We continue to use UnsafeAtomicHelper there so
       * that we don't change the performance there, for better or for worse.) Fortunately, JVM

available CPUs. Not including hyper-threading.
If you want to explicitly specify the number of JVMs you can do so on the command
line:

----------------------------
./gradlew test -Dtests.jvms=8
----------------------------

Or in `~/.gradle/gradle.properties`:

----------------------------
systemProp.tests.jvms=8
----------------------------

     * Compares cipher suites names like "TLS_RSA_WITH_NULL_MD5" and "SSL_RSA_WITH_NULL_MD5",
     * ignoring the "TLS_" or "SSL_" prefix which is not consistent across platforms. In particular
     * some IBM JVMs use the "SSL_" prefix everywhere whereas Oracle JVMs mix "TLS_" and "SSL_".
     */
    internal val ORDER_BY_NAME =
      object : Comparator<String> {
        override fun compare(
          a: String,
          b: String,
        ): Int {

        return "Unknown";
    }

    /**
     * Gets the instance ID for this Fess instance.
     * Combines scheduler.target.name (if configured), hostname, and PID
     * to ensure uniqueness across multiple JVMs on the same host.
     *
     * @return The instance ID.
     */
    public String getInstanceId() {
        final String targetName = ComponentUtil.getFessConfig().getSchedulerTargetName();

  // safely publish these objects and we won't need this whole discussion.
  // TODO(user,lukes): consider adding volatile to all these fields since in current known JVMs
  // that should resolve the issue. This comes at the cost of adding more write barriers to the
  // implementations.

  private Futures() {}

  /**

            test.setWorkingDir(project.file(project.getBuildDir() + "/testrun/" + test.getName()));
            test.setMaxParallelForks(Integer.parseInt(System.getProperty("tests.jvms", BuildParams.getDefaultParallel().toString())));

            test.exclude("**/*$*.class");

            test.jvmArgs(
                "-Xmx" + System.getProperty("tests.heap.size", "512m"),

## Version 3.14.9

_2020-05-17_

 *  Fix: Don't crash when running as a plugin in Android Studio Canary 4.1. To enable
    platform-specific TLS features OkHttp must detect whether it's running in a JVM or in Android.
    The upcoming Android Studio runs in a JVM but has classes from Android and that confused OkHttp!


## Version 3.14.8

_2020-04-28_

 *  Fix: Don't crash on Java 8u252 which introduces an API previously found only on Java 9 and