// TODO(b/192446998): Remove this override after tools understand nullness better.
  @CheckForNull
  public V put(K key, @ParametricNullness V value) {
    return super.put(key, value);
  }

  @CanIgnoreReturnValue
  @Override
  @SuppressWarnings("RedundantOverride") // b/192446478: RedundantOverride ignores some annotations.
  // TODO(b/192446998): Remove this override after tools understand nullness better.
  @CheckForNull

     * The returned list may contain a mix of Java class-path, Java module-path, and other types of path elements.
     *
     * @return the paths of all dependencies
     */
    @Nonnull
    List<Path> getPaths();

    /**
     * Returns the file paths of all dependencies, dispatched according the tool options where to place them.

  // TODO(b/192446998): Remove this override after tools understand nullness better.
  @CheckForNull
  public V put(K key, @ParametricNullness V value) {
    return super.put(key, value);
  }

  @CanIgnoreReturnValue
  @Override
  @SuppressWarnings("RedundantOverride") // b/192446478: RedundantOverride ignores some annotations.
  // TODO(b/192446998): Remove this override after tools understand nullness better.
  @CheckForNull

                            // Since JDK 11, package-list is missing from javadoc output files and superseded by element-list file, but a lot of external tools still need it
                            // Here we generate this file manually
                            copySpec.from(generatedJavadocDirectory.file("element-list"), sub -> {

        @SuppressWarnings("deprecation")
        List<Artifact> artifacts = project.getCompileArtifacts();
        assertEquals(1, artifacts.size());
        assertThat(artifacts.get(0).getFile().getName(), endsWith("tools.jar"));
    }

    @Nonnull
    PathScope getPathScope();

    /**
     * Returns a filter for the types of path (class-path, module-path, …) accepted by the tool.
     * For example, if a Java tools accepts only class-path elements, then the filter should return
     * {@code true} for {@link JavaPathType#CLASSES} and {@code false} for {@link JavaPathType#MODULES}.

 * I'm not completely sure that this is the right choice, but it has various advantages:
 *
 * <ul>
 *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
 *       suppression. This would follow the precedent of many of our annotation processors, which
 *       look for any annotation named, e.g., "GwtIncompatible," regardless of package.

 * I'm not completely sure that this is the right choice, but it has various advantages:
 *
 * <ul>
 *   <li>An annotation named just "Suppress" might someday be treated by a non-Android tool as a
 *       suppression. This would follow the precedent of many of our annotation processors, which
 *       look for any annotation named, e.g., "GwtIncompatible," regardless of package.

     * then the path type is determined by checking if the dependency is modular.</p>
     *
     * @param types types of path where a dependency can be placed
     * @param filter filter the paths accepted by the tool which will consume the path
     * @param path path to the JAR file or output directory of the dependency
     * @return where to place the dependency, or an empty value if the placement cannot be determined

        append(buf, "committed", () -> mem.getNonHeapCommitted().getBytes());
        buf.append('}');
        buf.append("},");
        final List<BufferPool> bufferPools = jvmStats.getBufferPools();
        buf.append("\"pools\":{");
        buf.append(bufferPools.stream().map(p -> {
            final StringBuilder b = new StringBuilder();
            b.append('"').append(StringEscapeUtils.escapeJson(p.getName())).append("\":{");