private static final byte[] ARRAY234 = {(byte) 2, (byte) 3, (byte) 4};

  private static final byte[] VALUES = {Byte.MIN_VALUE, -1, 0, 1, Byte.MAX_VALUE};

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

    // java.security.KeyStoreException: Certificate chain is not valid
    // at sun.security.pkcs12.PKCS12KeyStore.setKeyEntry
    // http://openjdk.java.net/jeps/229
    // http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/2c1c21d11e58/src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#l596
    val keystoreType = if (platform.isJdk9()) "JKS" else null
    val x509KeyManager = newKeyManager(keystoreType, heldCertificate, *intermediates)

   * elements will appear in the returned list in the same order they appeared in {@code elements}.
   *
   * <p><b>Performance note:</b> According to our
   * benchmarking
   * on Open JDK 7, {@link #immutableSortedCopy} generally performs better (in both time and space)
   * than this method, and this method in turn generally performs better than copying the list and
   * calling {@link Collections#sort(List)}.
   */

    INSTANCE;

    @Override
    public int compare(boolean[] left, boolean[] right) {
      // do not static import Math.min due to https://bugs.openjdk.org/browse/JDK-8357219
      @SuppressWarnings("StaticImportPreferred")
      int minLength = Math.min(left.length, right.length);
      for (int i = 0; i < minLength; i++) {
        int result = Boolean.compare(left[i], right[i]);

        </field>
        <field>
          <name>jdk</name>
          <version>4.0.0+</version>
          <type>String</type>
          <description>
            Specifies that this profile will be activated when a matching JDK is detected.
            For example, {@code 1.4} only activates on JDKs versioned 1.4,
            while {@code !1.4} matches any JDK that is not version 1.4. Ranges are supported too:

   *       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
   *       simply switch over to use the JDK implementation wholesale if probable hash flooding is
   *       detected, sacrificing the compactness guarantee in very rare cases in exchange for much
   *       more reliable worst-case behavior.

   * might not (and the answer might change while we're building the array).
   *
   * TODO: cpovirk - Is this an issue anywhere anymore? It looks to have been fixed for Java 8
   * (https://bugs.openjdk.org/browse/JDK-7121314) and before Lollipop
   * (https://r.android.com/47508). We *would* need to worry for J2KT, whose own concurrency support
   * is evolving (b/381065164, b/458160722), but this class is @J2ktIncompatible.
   *

      return Types.toString(type);
    }

    boolean jdkTypeDuplicatesOwnerName() {
      return true;
    }
  }

  /**
   * Per <a href="https://github.com/google/guava/issues/1635">issue 1635</a>, In JDK 1.7.0_51-b13,
   * {@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

  }

  /*
   * TODO: b/381289911 - Make the Iterator overload use StringJoiner (including Android or not)—or
   * some other optimization, given that StringJoiner can over-allocate:
   * https://bugs.openjdk.org/browse/JDK-8305774
   */

  // TODO: b/381289911 - Optimize MapJoiner similarly to Joiner (including Android or not).

  /**
   * Returns a string containing the string representation of each of {@code parts}, using the

   * might not (and the answer might change while we're building the array).
   *
   * TODO: cpovirk - Is this an issue anywhere anymore? It looks to have been fixed for Java 8
   * (https://bugs.openjdk.org/browse/JDK-7121314) and before Lollipop
   * (https://r.android.com/47508). We *would* need to worry for J2KT, whose own concurrency support
   * is evolving (b/381065164, b/458160722), but this class is @J2ktIncompatible.
   *