A few years ago, I was reviewing a junior developer's code for a batch processing system. He had written a cleanup routine using the old java.io.File API. The logic was simple: find a directory of old logs and delete them. The problem was that he was calling file.delete(), which returns a boolean. One day, the process failed in production because of a permission change on the server. The code didn't crash; it just silently received false from the delete method and kept moving. We spent four hours hunting down a "ghost" bug because the API didn't tell us why it failed—it just didn't work.

That's the primary reason we moved to NIO.2 (introduced in Java 7). The old File class was an awkward hybrid of a path and a file handle, and its error handling was abysmal. NIO.2 separates the location of the file from the operations performed on it, providing a much more robust, exception-driven framework that actually tells you when things go wrong.

Paths as Addresses, Files as the Toolkit

In NIO.2, you'll stop using java.io.File and start using java.nio.file.Path and java.nio.file.Files. Think of a Path as just a coordinate or an address; it doesn't actually check if the file exists on the disk. To actually do something—like reading, writing, or deleting—you pass that path into the Files utility class.

I usually prefer Path.of() (in newer Java versions) or Paths.get() to initialize these. It handles the platform-specific separators for you, so you aren't hardcoding backslashes and breaking your code the moment it moves from Windows to Linux.

Path configPath = Path.of("etc", "app", "config.properties");
if (Files.exists(configPath)) {
    // Now we actually do something with it
    byte[] data = Files.readAllBytes(configPath);
}

The magic here is that if Files.readAllBytes fails, it throws an IOException with a specific message (like "Access Denied"), rather than just returning null or false. It forces you to handle the failure, which is exactly what you want when dealing with the unpredictability of a file system.

Walking the File Tree and Streamlined I/O

One of the most powerful additions in NIO.2 is the ability to treat the file system as a stream. If you've ever written a recursive function to find all .txt files in a folder and its subfolders, you know it's a recipe for a StackOverflowError if the directory structure is deep enough. NIO.2 solves this with Files.walk.

Files.walk returns a Stream<Path>, allowing you to use functional programming to filter and process files. I've found this incredibly useful for implementing custom search tools or cleanup scripts. Just remember: Files.walk opens a resource, so you must use a try-with-resources block to ensure the stream is closed.

try (Stream<Path> paths = Files.walk(Path.of("/var/logs"), 3)) {
    paths.filter(Files::isRegularFile)
         .filter(p -> p.toString().endsWith(".log"))
         .forEach(System.out::println);
} catch (IOException e) {
    e.printStackTrace();
}

Beyond walking trees, NIO.2 simplified the "small file" problem. Instead of setting up a BufferedReader, a FileReader, and a while loop just to read a few lines of a config file, you can now use Files.readAllLines() or Files.write(). It's cleaner, faster to write, and much harder to mess up.

📋 Practical Task

Build a Recursive Log Archive Utility

Create a program that scans a specified root directory (and all its sub-directories) for files ending in .log. For every log file found that is older than 30 days, the program should move the file into a folder named /archive located at the root of the search path.

Requirements:

• Use Files.walk to traverse the directory structure.
• Use Files.getLastModifiedTime to check the age of the file.
• Use Files.move to relocate the files.
• Ensure the /archive directory is created using Files.createDirectories if it doesn't already exist.
• Properly handle IOException using try-catch blocks to ensure the program doesn't crash if a single file is locked by another process.