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 JVM_DLL=\bin\server\jvm.dll
	goto foundJVM
)

rem Fallback to 'client' JRE
if exist "%JAVA_HOME%"\bin\client\jvm.dll (
	set JVM_DLL=\bin\client\jvm.dll
	echo Warning: JAVA_HOME points to a JRE and not JDK installation; a client (not a server^) JVM will be used...
) else (
	echo JAVA_HOME points to an invalid Java installation (no jvm.dll found in "%JAVA_HOME%"^). Exiting...
	goto:eof
)

:foundJVM

   * Comparable<? super E>} in order to accommodate users of obsolete javac versions affected by <a
   * href="https://bugs.openjdk.org/browse/JDK-6468354">JDK-6468354</a>.
   */
  public static <E extends Comparable<?>> Builder<E> reverseOrder() {
    return new Builder<>(Ordering.<E>natural().reverse());
  }

  /**

   * 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

    Throwable thrownReflectionFailure = null;
    try {
      helper = new SafeAtomicHelper();
    } catch (Throwable reflectionFailure) { // sneaky checked exception
      // Some Android 5.0.x Samsung devices have bugs in JDK reflection APIs that cause
      // getDeclaredField to throw a NoSuchFieldException when the field is definitely there.
      // For these users fallback to a suboptimal implementation, based on synchronized. This will

    return new SingletonImmutableSet<>(e1);
  }

  /*
   * TODO: b/315526394 - Skip the Builder entirely for the of(...) methods, since we don't need to
   * worry that we might trigger the fallback to the JDK-backed implementation? (The varargs one
   * _could_, so we could keep it as it is. Or we could convince ourselves that hash flooding is
   * unlikely in practice there, too.)
   */

  /**

  private static final char GREATEST = Character.MAX_VALUE;

  private static final char[] VALUES = {LEAST, 'a', '\u00e0', '\udcaa', GREATEST};

  // We need to test that our method behaves like the JDK method.
  @SuppressWarnings("InlineMeInliner")
  public void testHashCode() {
    for (char value : VALUES) {
      assertThat(Chars.hashCode(value)).isEqualTo(Character.hashCode(value));
    }
  }

   * even worse. For now, we just suppress and move on with our lives.
   *
   * - https://github.com/jspecify/jspecify/issues/65
   *
   * - https://github.com/jspecify/jdk/commit/71d826792b8c7ef95d492c50a274deab938f2552
   */
  /*
   * TODO(cpovirk): Is the unchecked cast avoidable? Would System.arraycopy be similarly fast (if

    return longBitsToDouble(significand | ONE_BITS);
  }

  static double bigToDouble(BigInteger x) {
    // This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending.
    BigInteger absX = x.abs();
    int exponent = absX.bitLength() - 1;
    // exponent == floor(log2(abs(x)))
    if (exponent < Long.SIZE - 1) {
      return x.longValue();

      assertThat(cache.asMap().values()).contains(value2);
      assertThat(cache.asMap().entrySet()).containsExactly(immutableEntry(key2, value2));
    }
  }

  // fails in Maven with 64-bit JDK: https://github.com/google/guava/issues/1568

  // A simple type whose .toString() will return the same value each time, but without maintaining
  // a strong reference to that value.
  static class Key {