* depending on whether {@link #CLASSES} or {@link #MODULES} is present.
     * </p>
     *
     * @param moduleName name of the module on which to apply the path
     * @return an identification of the patch-module path for the given module.
     *
     * @see Modular#moduleName()
     */
    @Nonnull
    public static Modular patchModule(@Nonnull String moduleName) {

     */
    private static final String MODULE_INFO = "module-info.class";

    /**
     * The attribute for automatic module name in {@code META-INF/MANIFEST.MF} files.
     */
    private static final Attributes.Name AUTO_MODULE_NAME = new Attributes.Name("Automatic-Module-Name");

    /**
     * Module information for the path specified at construction time.

cc_library(
    name = "modular_filesystem",
    srcs = [
        "modular_filesystem.cc",
        "modular_filesystem_registration.cc",
    ],
    hdrs = [
        "modular_filesystem.h",
        "modular_filesystem_registration.h",
    ],
    # TODO(b/139060984): Visibility should be more restrictive once we
    # convert to modular filesystems everywhere
    visibility = ["//visibility:public"],

     * Java does not accept the placement of two modules of the same name on the module-path.
     * So the modular test output directory usually needs to be placed in a {@code --path-module} option.
     *
     * <ul>
     *   <li>If the test output directory is modular, then:
     *     <ul>
     *       <li>If a test module name is identical to a main module name,

     * If the JAR is modular, its module information are ignored.
     * This type is new in Maven 4.
     */
    String CLASSPATH_JAR = "classpath-jar";

    /**
     * Artifact type name for a JAR file to unconditionally place on the module-path.
     * If the JAR is not modular, then it is loaded by Java as an unnamed module.
     * This type is new in Maven 4.
     */

     * Java does not accept the placement of two modules of the same name on the module-path.
     * So the modular test output directory usually needs to be placed in a {@code --path-module} option.
     *
     * <ul>
     *   <li>If the test output directory is modular, then:
     *     <ul>
     *       <li>If a test module name is identical to a main module name,

     */
    private static final String MODULE_INFO = "module-info.class";

    /**
     * The attribute for automatic module name in {@code META-INF/MANIFEST.MF} files.
     */
    private static final Attributes.Name AUTO_MODULE_NAME = new Attributes.Name("Automatic-Module-Name");

    /**
     * Module information for the path specified at construction time.

     * This method does not handle the patch-module paths, because the patches
     * depend on which modules have been previously added on the module-paths.
     *
     * <p>If the dependency can be a constituent of both the class-path and the module-path,
     * 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

     * This method does not handle the patch-module paths, because the patches
     * depend on which modules have been previously added on the module-paths.
     *
     * <p>If the dependency can be a constituent of both the class-path and the module-path,
     * 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

        "//tensorflow/c/experimental/filesystem:modular_filesystem",
        "//tensorflow/core/platform:status",
        "@com_google_absl//absl/log",
    ],
    alwayslink = 1,
)

# Library implementing helper functionality, so that the above only contains
# the API implementation for modular filesystems.
cc_library(
    name = "posix_filesystem_helper",