// If add is supported, verify that IMMUTABLE is not reported.
    assertFalse(collection.spliterator().hasCharacteristics(Spliterator.IMMUTABLE));
  }

  @CollectionFeature.Require(SUPPORTS_REMOVE)
  public void testSpliteratorNotImmutable_collectionAllowsRemove() {
    // If remove is supported, verify that IMMUTABLE is not reported.
    assertFalse(collection.spliterator().hasCharacteristics(Spliterator.IMMUTABLE));

    // If add is supported, verify that IMMUTABLE is not reported.
    assertFalse(collection.spliterator().hasCharacteristics(Spliterator.IMMUTABLE));
  }

  @CollectionFeature.Require(SUPPORTS_REMOVE)
  public void testSpliteratorNotImmutable_collectionAllowsRemove() {
    // If remove is supported, verify that IMMUTABLE is not reported.
    assertFalse(collection.spliterator().hasCharacteristics(Spliterator.IMMUTABLE));

(Older toolchains ignore `//go:debug` directives entirely.)

The defaults that will be compiled into a main package
are reported by the command:

{{raw `
	go list -f '{{.DefaultGODEBUG}}' my/main/package
`}}

Only differences from the base Go toolchain defaults are reported.

When testing a package, `//go:debug` lines in the `*_test.go`
files are treated as directives for the test's main package.

    Settings getEffectiveSettings();

    /**
     * Gets the problems that were encountered during the settings building. Note that only problems of severity
     * {@link SettingsProblem.Severity#WARNING} and below are reported here. Problems with a higher severity level cause
     * the settings builder to fail with a {@link SettingsBuildingException}.
     *

   * href="http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html">efficiently splittable</a>
   * if and only if {@code stream} was efficiently splittable and its underlying spliterator
   * reported {@link Spliterator#SUBSIZED}. This is generally the case if the underlying stream
   * comes from a data structure supporting efficient indexed random access, typically an array or
   * list.
   *

    /**
     * OS family that can be tested for. {@value}
     */
    private static final String FAMILY_OS400 = "os/400";

    /**
     * OpenJDK is reported to call MacOS X "Darwin"
     *
     * @see <a href="https://issues.apache.org/bugzilla/show_bug.cgi?id=44889">bugzilla issue</a>
     * @see <a href="https://issues.apache.org/jira/browse/HADOOP-3318">HADOOP-3318</a>

    List<Profile> getActiveExternalProfiles();

    /**
     * Gets the problems that were encountered during the model building. Note that only problems of severity
     * {@link ModelProblem.Severity#WARNING} and below are reported here. Problems with a higher severity level cause
     * the model builder to fail with a {@link ModelBuildingException}.
     *

   * href="http://gee.cs.oswego.edu/dl/html/StreamParallelGuidance.html">efficiently splittable</a>
   * if and only if {@code stream} was efficiently splittable and its underlying spliterator
   * reported {@link Spliterator#SUBSIZED}. This is generally the case if the underlying stream
   * comes from a data structure supporting efficient indexed random access, typically an array or
   * list.
   *

                try {
                    fixTimestamp(file, readMetadata(file), ((RepositoryMetadata) metadata).getMetadata());
                } catch (RepositoryMetadataReadException e) {
                    // will be reported via storeInlocalRepository
                }
            }
        } else {
            // It's a POM - we don't need to retrieve it first
            file = new File(

 *
 * <p>The one downside of {@code Stopwatch} relative to {@link System#nanoTime()} is that {@code
 * Stopwatch} requires object allocation and additional method calls, which can reduce the accuracy
 * of the elapsed times reported. {@code Stopwatch} is still suitable for logging and metrics where
 * reasonably accurate values are sufficient. If the uncommon case that you need to maximize
 * accuracy, use {@code System.nanoTime()} directly instead.
 *