demonstrating the bug.
      render: java
    validations:
      required: true

  - type: textarea
    attributes:
      label: Expected Behavior
      description: What did you expect to happen?
    validations:
      required: true

  - type: textarea
    attributes:
      label: Actual Behavior
      description: What actually happened?
    validations:
      required: true

 * #iterator()} method after the first, and whose iterator is always unmodifiable.
 *
 * <p>The {@code Iterable} specification does not make it absolutely clear what should happen on a
 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind

        // This will make sure that tasks don't get stuck busy waiting.
        // Some of this is fixed in jdk11 (see https://bugs.openjdk.org/browse/JDK-8198692) but
        // not all.  See the test cases for examples on how this can happen.
        try {
          ((Thread) currentRunner).interrupt();
        } finally {
          Runnable prev = getAndSet(DONE);
          if (prev == PARKED) {
            LockSupport.unpark((Thread) currentRunner);

   * Futures#addCallback addCallback()}.
   *
   * <p>Memory consistency effects: Actions in a thread prior to adding a listener <a
   * href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.4.5">
   * <i>happen-before</i></a> its execution begins, perhaps in another thread.
   *
   * <p>Guava implementations of {@code ListenableFuture} promptly release references to listeners
   * after executing them.
   *

    // - even for the JVM in our open-source release (https://github.com/google/guava/issues/3147)
    // If anyone in our monorepo uses the Android copy of Guava on a JVM, that would be unfortunate.
    // But that is only likely to happen in Robolectric tests, where the risks of JDK regex are low.
    return new JdkPatternCompiler();
  }

  private static final class JdkPatternCompiler implements PatternCompiler {
    @Override

      val toVerify = result[result.size - 1] as X509Certificate

      // If this cert has been signed by a trusted cert, use that. Add the trusted certificate to
      // the end of the chain unless it's already present. (That would happen if the first
      // certificate in the chain is itself a self-signed and trusted CA certificate.)
      val trustedCert = trustRootIndex.findByIssuerAndSignature(toVerify)
      if (trustedCert != null) {

            if (longValue > Integer.MAX_VALUE) {
                return null;
            }
            return (int) longValue;
        } catch (NumberFormatException e) {
            // should never happen since checked isDigits(s) before
            return null;
        }
    }

    @Override
    public String toString() {
        return comparable.toString();
    }

 *       continuing to run {@code FooTest} itself. This is exactly what happens with {@code
 *       AndroidIncompatible}. But I'm not sure what would happen if we annotated the {@code
 *       suite()} method with {@code Suppress}. Would {@code FooTest} itself be suppressed, too?
 *   <li>In at least one case, a use of {@code sun.misc.FpUtils}, the test will not even

     * @see jcifs.SmbResourceLocator#isRoot()
     */
    @Override
    public boolean isRoot() {
        // length == 0 should not happen
        return getShare() == null && getUNCPath().length() <= 1;
    }

    boolean isRootOrShare() {
        // length == 0 should not happen
        return getUNCPath().length() <= 1;
    }

    /**
     * @throws MalformedURLException
     *
     */

  }

  @Override
  public <T> T[] toArray(T[] a) {
    return delegate.toArray(a);
  }

  @CanIgnoreReturnValue
  private <T> T checkValid(T t) {
    // a ClassCastException is what's supposed to happen!
    @SuppressWarnings("unchecked")
    E e = (E) t;
    int unused = comparator().compare(e, e);
    return t;
  }

  @Override
  public boolean equals(@Nullable Object obj) {