What architectural advantage does the FileSystem provider abstraction in NIO.2 give that java.io.File cannot, and how would you exploit it?

## The limitation of `java.io.File` A `java.io.File` always means a location on the **default OS filesystem** — your real disk. There is no abstraction layer: `File` *is* the disk. You cannot point the same `File`-based code at a ZIP archive, a remote object store, or a fake in-memory disk. This makes `File`-based I/O hard to test (you need a real temp directory and cleanup) and impossible to redirect. ## The NIO.2 abstraction NIO.2 was designed around a **Service Provider Interface (SPI)** called `java.nio.file.spi.FileSystemProvider`. The layering is: - A **`FileSystemProvider`** is a backend implementation (disk, zip, in-memory, cloud). - A **`FileSystem`** is an instance produced by a provider (one mounted disk, one open zip). - A **`Path`** *belongs to* a specific `FileSystem` (`path.getFileSystem()`). - **`Files`** dispatches each operation to the provider of the `Path`'s filesystem. Because every operation routes through the provider, **the same `Path`/`Files` code runs unchanged against any backend**. That is the architectural payoff `File` can never give. ### Built-in: the ZIP/JAR filesystem The JDK ships a zip provider. You can mount a `.zip`/`.jar` as a `FileSystem` and manipulate its entries as ordinary `Path`s: ```java try (FileSystem zip = FileSystems.newFileSystem(Path.of("archive.zip"))) { Path entry = zip.getPath("/dir/file.txt"); Files.writeString(entry, "hello"); // writes INTO the zip } ``` No manual `ZipInputStream` plumbing — your normal `Files` code works inside the archive. ### Third-party providers - **Jimfs** (Google): an in-memory filesystem provider — perfect for tests. - **S3/GCS providers**: treat cloud object stores as filesystems. ## Exploiting it: testability via dependency injection The principal-level move is to **treat the filesystem as an injected dependency**. Instead of hard-coding `Path.of(...)` (which resolves against the default disk), pass in a `FileSystem` (or a root `Path`) and build paths from it: ```java class ReportWriter { private final Path root; ReportWriter(Path root) { this.root = root; } // injected void write(String name, String body) throws IOException { Files.writeString(root.resolve(name), body); } } // Production: real disk new ReportWriter(Path.of("/var/reports")); // Test: in-memory FS (Jimfs) — fast, isolated, no disk, no cleanup try (FileSystem fs = Jimfs.newFileSystem(Configuration.unix())) { var writer = new ReportWriter(fs.getPath("/reports")); // ... assert on the in-memory contents } ``` Benefits: tests are **fast** (RAM, no I/O), **isolated** (each test its own FS, no shared temp dirs), **OS-independent** (configure unix/windows semantics), and need **no cleanup**. None of this is possible with `File`. ## Key terms - **SPI (Service Provider Interface)**: an extension point where pluggable implementations register and are discovered at runtime. - **Provider / FileSystem / Path layering**: provider = backend type; FileSystem = a mounted instance; Path = a location within one FileSystem. - **In-memory filesystem**: a FileSystem whose data lives in RAM, used mainly for testing. ## The catch — don't leak `File` `Path.toFile()` only works on the **default** provider; calling it on a zip/in-memory path throws `UnsupportedOperationException`. So once you embrace non-default filesystems, you must stay fully within `Path`/`Files` and avoid any code path that downgrades a `Path` to a `File`. This is exactly why a principal sets the convention: **public APIs speak `Path`, never `File`**, so the provider abstraction is preserved end to end.