Path vs File in Java
java.io.File and java.nio.file.Path both represent a file or folder location. File is the original class from Java 1.0; Path is part of NIO.2, added in Java 7 to fix File's weaknesses. The biggest practical difference is error handling: many File methods report failure by quietly returning false, while Files methods throw an exception that says exactly what went wrong. In this lesson, you will compare them side by side.
Example: The Same Failure, Two Ways
Let's see an example that tries to delete a file that doesn't exist.
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
public class DeleteCompare {
public static void main(String[] args) {
File oldWay = new File("missing.txt");
boolean deleted = oldWay.delete();
System.out.println("File.delete() returned " + deleted);
try {
Files.delete(Path.of("missing.txt"));
} catch (IOException e) {
System.out.println("Files.delete() threw "
+ e.getClass().getSimpleName() + ": " + e.getMessage());
}
}
}File.delete() returned false
Files.delete() threw NoSuchFileException: missing.txtExplanation: File.delete() returns false, but it doesn't say why: the file might be missing, locked, or not allowed. Files.delete throws NoSuchFileException, which names the exact problem. With File, it's also easy to forget to check the returned boolean at all.
Differences Between File and Path
java.io.File | java.nio.file.Path + Files | |
|---|---|---|
| Package | java.io | java.nio.file |
| Introduced | Java 1.0 | Java 7 |
| Type | A class | An interface (plus the Files utility class) |
| Error reporting | Many methods return boolean | Descriptive exceptions |
| Symbolic links | Not supported properly | Full support |
| File attributes and permissions | Very limited | Full (readAttributes, POSIX permissions) |
| Reading and writing whole files | Not built in | readString, writeString, readAllLines |
| Walking a tree | Manual recursion with listFiles() | Files.walk, Files.find |
| Watching folders | No | WatchService |
| Path operations | Few | resolve, relativize, normalize |
Converting Between Them
import java.io.File;
import java.nio.file.Path;
public class Convert {
public static void main(String[] args) {
File file = new File("reports", "marks.csv");
Path path = file.toPath();
File back = path.toFile();
System.out.println(file + " -> " + path + " -> " + back);
System.out.println(path.getFileName() + " in " + path.getParent());
}
}reports/marks.csv -> reports/marks.csv -> reports/marks.csv
marks.csv in reportsExplanation: file.toPath() and path.toFile() convert in either direction with no loss, so you can use Path in your own code and still call older libraries that need a File.
Common Mistakes
Ignoring the boolean result of File.delete(), mkdir() or renameTo(). Failures go unnoticed.
Using File.renameTo to move files across disks. It often fails silently; use Files.move.
Thinking Path is a class. It's an interface; create paths with Path.of.
Interview Corner
Why is Path preferred over File?
NIO.2's Path with Files reports failures through specific exceptions instead of false return values, supports symbolic links, file attributes and permissions, offers convenient methods to read and write whole files and to walk directory trees, provides path operations such as resolve and normalize, and works with WatchService. java.io.File lacks most of these and makes silent failures easy. The two convert with toPath() and toFile().
Practice
- Easy: Try
new File("a/b/c").mkdir()andFiles.createDirectory(Path.of("a/b/c"))whena/bdoesn't exist, and compare what each reports. - Harder: Rewrite a method that lists the
.txtfiles in a folder usingFile.listFiles()so that it usesFiles.listand a stream instead.
Key Takeaways
Was this tutorial helpful?