tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

    tests, either. This causes it to fail to find AtomicLongMapTest.

    Our workaround is to tell GWT that util.concurrent and all other packages
    have prod supersource, even if they have none. GWT is happy to ignore us
    when we specify a nonexistent path.

    (I hope that this workaround does not cause its own problems in the future.)
-->
<super-source path="super"/>

        }

        if (connectResult.isSuccess) {
          // We have a connected TCP connection. Cancel and defer the racing connects that all lost.
          cancelInFlightConnects()

          // Finish connecting. We won't have to if the winner is from the connection pool.
          if (!connectResult.plan.isReady) {

        // Verify that multiple threads were processed
        assertTrue("Should process at least one thread", threadCount.get() >= 1);
        assertTrue("Should have stack trace elements", stackTraceCount.get() > 0);
        assertTrue("Should have more stack traces than threads", stackTraceCount.get() > threadCount.get());
    }

    public void test_processThreadDump_withException() {

 * second invocation, so implementors have made various choices, including:
 *
 * <ul>
 *   <li>returning the same iterator again
 *   <li>throwing an exception of some kind
 *   <li>or the usual, <i>robust</i> behavior, which all known {@link Collection} implementations
 *       have, of returning a new, independent iterator
 * </ul>
 *

  /*
   * Ideally, this class would have exposed only constructors that require a non-null cause. See
   * https://github.com/jspecify/jspecify-reference-checker/blob/61aafa4ae52594830cfc2d61c8b113009dbdb045/src/main/java/com/google/jspecify/nullness/NullSpecTransfer.java#L789
   * and https://github.com/jspecify/jspecify/issues/490.
   *
   * (That would also have ensured that its cause was always an Error, rather than possibly another

     * @return An iterator of URL objects for the resources. If no resources are found, the iterator will be empty.
     *         Resources that the class loader does not have access to will not be included.
     * @see java.lang.ClassLoader#getResources(String)
     */
    public static Iterator<URL> getResources(final String name) {
        assertArgumentNotEmpty("name", name);

        assertNotNull("Parameter annotations should exist", paramAnnotations);
        assertEquals("Should have one parameter", 1, paramAnnotations.length);
        assertEquals("Parameter should have one annotation", 1, paramAnnotations[0].length);

        final UriType annotation = (UriType) paramAnnotations[0][0];