Path and Files: modern file handling

In the last few lessons you read files with a BufferedReader and wrote them with a BufferedWriter. Those classes still work, but they make you write the same loop and the same try-with-resources block every time. Java has a newer pair for files, Path and Files, that does each everyday job in a single call: read a whole file, write a whole file, add a line to the end, copy, move, delete. This lesson teaches the pair, then puts it to work on a real task: turning a CSV file of grades into a report.

One call instead of a loop#

Start with a job you already know: read every line of shopping.txt into a list. The program below does it twice. The first half is the java.io way from the reading files lesson. The second half is the new way. Press Run and step through. Watch oldWay grow by one line on each pass of the loop, then watch newWay arrive whole, in a single step.

bread
eggs
coffee

Both lists print as [bread, eggs, coffee], and equals prints true. The first version needed a reader wrapped around another reader, a loop with two readLine calls, a null check and a try-with-resources block. The second version is one line. Files.readAllLines opens the file, reads every line into a list, and closes the file again before it gives you the list.

Two names do that work, and both live in the package java.nio.file. A Path holds the name and location of a file. Files is a class made only of static methods that act on files: reading, writing, copying, moving, deleting and more. You never make a Files object. You call its methods on the class name, as in Files.readAllLines(...), the same way you call Math.max(...).

Key idea

The Files methods that read or write a whole file do the job in one call. Each one opens the file, reads or writes all of it, and closes it again before it returns, so there is nothing left for you to close.

Path: the name of a place on disk#

A Path is the name of a place on disk, written the way the operating system writes it: a file name on its own, or folder names and a file name joined by a separator. You make one with Path.of, giving it the whole name or the parts one by one. This program starts with one file on its disk, notes.txt.

Buy milk
Walk the dog

Line by line:

• Path.of("notes.txt") names a file called notes.txt. Printing a Path prints the name.
• Path.of("reports", "2026", "march.csv") joins its parts with the separator your system uses, so it prints reports/2026/march.csv here. On Windows the same line prints reports\2026\march.csv, and your code does not have to change.
• getFileName() gives the last part, march.csv. getParent() gives everything before it, reports/2026. A path with only one part, like notes.txt, has no parent, and getParent() returns null.
• reports.resolve("april.csv") joins a folder path and a name: reports/april.csv. It is handy when one folder holds many files.
• Files.exists is the first line that looks at the disk. It prints true for notes.txt, which is there, and false for march, which is not.

Look at march again. It names a file inside two folders that do not exist, and Java made the Path anyway, printed it, and took it apart. A Path is like the address on an envelope: writing the address does not build the house, and it does not check that the house is there. Nothing happens on disk until you hand the Path to a Files method. Step through again and watch the Files section of the memory view. It shows notes.txt the whole time, and no other file ever appears.

Key idea

A Path names a place on disk; it is not the file. Making one never opens, creates or checks anything, so you can make a Path for a file that does not exist yet.

Relative and absolute paths

Every path in this lesson is relative: notes.txt means the file called notes.txt in the program's working directory, the folder it runs in, as you saw in writing files. An absolute path starts from the top of the disk, like /Users/ada/notes.txt on a Mac or C:\Users\ada\notes.txt on Windows. A program with an absolute path written into it only works on computers that have that exact folder, so prefer relative paths, built from parts with Path.of, and let Java choose the separator.

Reading a whole file#

Files gives you two ways to read a whole file. Files.readString(path) gives you everything in it as one String. Files.readAllLines(path) cuts the text at its line breaks and gives you a List<String>, one element per line. Here is the same recipe read both ways.

2 eggs
1 cup of flour
1 cup of milk

readString found 36 characters: the 33 letters, digits and spaces you can see, plus three line breaks, because a line break is a character too. That is why System.out.print, with no ln, still prints the recipe on three lines: the line breaks are inside the text. readAllLines used those same line breaks to decide where each element ends and left them out, so the list holds three clean lines, ready for a loop.

Very big files: Files.lines

Files.lines(path) reads a file lazily: it fetches the next line only when it is needed, so memory holds a few lines at a time, however long the file is. It hands you the lines as a Stream<String>, a sequence you process with a chain of steps. Streams get a lesson of their own later. Here is just enough of them to count the error lines in a server log.

INFO  server started
INFO  user ada logged in
ERROR disk almost full
INFO  user ada logged out
ERROR disk full

filter keeps the lines that pass the test in the lambda, and count counts what is left, so the program prints 2 lines start with ERROR. One rule matters even before you learn streams. readAllLines closes the file before it returns, but Files.lines keeps the file open while you work through the lines, so the stream must be closed when you are done. Opening it in a try-with-resources block, as here, closes it for you, exactly like the readers in reading files.

When the file is not there#

Any Files method that reads a file can fail: the file may be missing, or you may not have permission to read it. Every one of these failures is an IOException, the checked exception from exception handling, so the compiler makes you either catch it or declare throws IOException. The programs so far declared it on main, which means a missing file would crash them. This program catches the failure instead and carries on. It starts with an empty disk.

There is no settings.txt, so readString throws a NoSuchFileException. Its message is the path itself, settings.txt, which the catch block puts into a sentence before the program goes on with default settings. The older FileReader reports the same problem as a FileNotFoundException; the Files methods use NoSuchFileException.

NoSuchFileException belongs to the IOException family, so the second block, catch (IOException e), would catch it too. Catching it by name first lets you treat “the file is not there”, which is often normal (on a program's very first run, say), differently from other read errors, which usually mean something has gone wrong.

Asking first with Files.exists

You can also ask before you read. Files.exists(path) returns true when there is a file at that path. This version starts with a settings.txt on its disk. Open it full screen, change the file name in the code to one that is not there, and run it again to see the other branch.

theme=dark

Writing a whole file#

Writing takes one call too. Files.writeString(path, text) creates the file if it is missing, throws away everything in it if it exists, writes your text, and closes the file. To add to the end instead, pass a third argument: StandardOpenOption.APPEND. This program starts with a diary.txt that already holds one line. Step through it and watch the Files section of the memory view, where the file a step changes is outlined.

Sunday: nothing yet

The first writeString wiped out the Sunday line and wrote Monday's. The call with APPEND added Tuesday's line after it. The last call, without APPEND, replaced both with Wednesday's line, so the second print shows only Wednesday: oops. It is the same choice you made in writing files between new FileWriter(name) and new FileWriter(name, true), written as an option instead of a true. writeString writes exactly the characters you give it and adds no line break of its own, so each string here ends with \n.

Key idea

Files.writeString replaces the whole file. Pass StandardOpenOption.APPEND when you want to keep what is there and add to the end.

A list of lines with Files.write

When your text is already a list of lines, Files.write(path, lines) writes each element and ends each one with a line break. Here is the to-do file from writing files once more. There it took a BufferedWriter, a loop of write and newLine calls, and a try-with-resources block. Here the loop only builds the list, and one call writes the file.

The file appears in the Files section with four lines, and readAllLines reads them back as [To do, - Buy milk, - Call Sam, - Finish notes]. Files.writeends every line, the last one included, with your system's line separator: \n on macOS and Linux, \r\n on Windows.

Why there is nothing to close

In writing files, a BufferedWriter held your text in a buffer until flush or close pushed it to the disk, and a forgotten close lost it. Files.writeString and Files.write open the file, write everything and close it inside the one call. By the time the method returns, the text is in the file, and you never hold a writer object, so there is no close to forget.

Project: a grades report from a CSV file#

CSV stands for comma-separated values. It is the plainest way to keep a table in a text file: one line per row, with commas between the values in that row. The first line usually holds the column names and is called the header. Every spreadsheet program can save a sheet as CSV and open one, so a lot of data travels between programs this way. A spreadsheet shows this lesson's file, grades.csv, like this:

The goal is a second file, report.csv, with each student's total and average mark. You will build the program in four steps.

Step 1: split each line into fields

Three moves turn the file into data. readAllLines gives one String per line. The header is element 0, so the loop starts at 1 to skip it. Inside the loop, line.split(",") cuts the line at every comma and gives back the pieces, called fields, as a String array.

name,maths,science,english,art
Aisha,91,85,78,94
Ben,64,72,59,70
Carmen,88,95,91,90
Elif,75,81,69,88

Step through and watch fields in the memory view. Each pass of the loop makes a new array of five strings: the name at index 0 and the four marks at indexes 1 to 4. The marks are still text. fields[1] is the string "91", because split only cuts text into smaller pieces of text.

A missing mark in the middle leaves an empty string, "", at its index, so b still has five fields. A missing mark at the end is different: split drops empty strings from the end of the array, so c has only four. If you need those empty fields kept, line.split(",", -1) keeps them.

Try the splitting yourself below. Edit any line, or add a tricky one with the buttons, and see how split cuts it and whether the finished report program, from step 4, keeps or skips it. The first switch changes every split to split(",", -1).

Step 2: totals, averages and a report file

Before you can add up the marks, each one has to become an int, which is the job of Integer.parseInt. The program below adds up each student's marks, works out the average, and collects one line per student for the report. Each report line is built by joining values with commas, the reverse of split, so the report is a CSV file too and opens in any spreadsheet. At the end, one Files.write call saves every line.

name,maths,science,english,art
Aisha,91,85,78,94
Ben,64,72,59,70
Carmen,88,95,91,90
Elif,75,81,69,88

report.csv appears in the Files section when Files.writeruns, all five lines at once. Aisha's marks add up to 348 and her average is 87.0; Ben's are 265 and 66.25. The average divides by fields.length - 1, the number of marks (every field except the name), so the program still works if a subject is added to the file. The cast in (double) total matters: without it, 265 / 4 is integer division, as in operators and casting, and Ben's average would come out as 66.0.

Step 3: one bad line stops everything

Real files are messier. Here is the same program, unchanged, run on a grades.csv that a busy teacher has edited by hand. Dev missed the science test, so his mark says absent, and Farah's line is missing two marks. Run it and step to the end.

name,maths,science,english,art
Aisha,91,85,78,94
Ben,64,72,59,70
Carmen,88,95,91,90
Dev,82,absent,77,80
Elif,75,81,69,88
Farah,90,85

Integer.parseInt("absent") throws a NumberFormatException, nothing catches it, and the program stops on Dev's line. Now look at the Files section: there is no report.csv. Aisha, Ben and Carmen were read without any trouble, but their lines were still waiting in the report list when the program died, before Files.write could run, so one bad line lost the whole report.

Step 4: check every line before you trust it

The fix needs two checks. First, before parsing, compare the line's field count with the header's. The header says how many columns a row should have, so the program reads that number from line 1 instead of writing 5 into the code. Second, put the parsing inside try/catch, so a mark that is not a number skips that one line instead of ending the program. Both checks print the line number and the reason, so whoever looks after the file can fix it.

name,maths,science,english,art
Aisha,91,85,78,94
Ben,64,72,59,70
Carmen,88,95,91,90
Dev,82,absent,77,80
Elif,75,81,69,88
Farah,90,85

It prints Line 5 skipped: For input string: "absent", then Line 7 skipped: 3 fields, expected 5, then Wrote 4 students to report.csv. Dev's line fails inside the try, and the catchtakes over for that line only. Farah's line fails the count check, and continue jumps straight to the next line, the same continue you met in loops. The four good students reach the report. The messages say i + 1 because the list counts from 0 while a text editor numbers lines from 1, so the header is line 1 and Dev is line 5.

Key idea

Treat every line of a file as something to check. Count its fields, parse inside a try, report and skip what fails, and the good lines still reach the report.

1import java.io.IOException;
2import java.nio.file.Files;
3import java.nio.file.Path;
4import java.util.List;
5 
6public class Main {
7    public static void main(String[] args) throws IOException {
8        // This line makes the file to read. Leave it as it is.
9        Files.write(Path.of("temps.csv"), List.of("day,celsius", "Mon,18", "Tue,21", "Wed,n/a", "Thu,24", "Fri,19"));
10 
11        String warmestDay = "none";
12        int warmest = Integer.MIN_VALUE;
13 
14        // TODO: read temps.csv, skip the header, and keep the warmest day and its temperature.
15        // Print "Skipped <day>: <text>" for a temperature that is not a whole number.
16 
17        Files.writeString(Path.of("warmest.txt"), warmestDay + " was the warmest at " + warmest + " C");
18        System.out.println(Files.readString(Path.of("warmest.txt")));
19    }
20}

Copy, move, delete and size#

Files also does the jobs you do by hand in a file manager. This program starts with a report.csv like the one the project wrote. Step through it and watch files appear and disappear in the Files section.

name,total,average
Aisha,348,87.0
Ben,265,66.25
Carmen,364,91.0
Elif,313,78.25

Files.size says the report is 79 bytes: one for each of the 74 characters you can see, and one for each of its five line breaks. copy makes backup.csv with the same contents. move renames report.csv to march-report.csv, so afterwards there is no report.csv any more, and the program prints false true. The second copy would fail, because backup.csv already exists, if it did not pass StandardCopyOption.REPLACE_EXISTING. Finally delete removes the backup, and deleteIfExists prints false because there was nothing left to delete.

A byte is not always a character. In UTF-8, plain English letters, digits and commas take one byte each, but a letter like é takes two and most emoji take four. So a file holding café and a line break is 6 bytes long, while readString gives you 5 characters.

Folders: listing and walking#

So far every file has sat in one folder. Real projects keep files in folders inside folders, and two Files methods look inside them. Files.list(folder) gives the entries directly inside one folder. Files.walk(folder) also goes down into every folder inside it, and every folder inside those, and so on. Both hand the entries back as a Stream<Path> that keeps the folder open, so they belong in try-with-resources too.

The in-browser engine keeps its files on a flat disk, without folders, so these two methods only run on a real computer. Here is a folder called school on a real disk:

Directly inside school:
  2025
  grades.csv
  notes.txt
Every CSV file, at any depth:
  school/2025/autumn.csv
  school/2025/spring.csv
  school/grades.csv

Files.list stopped at the first level: the folder 2025 is one of its entries, but the files inside it are not. Files.walk went into 2025 as well, and the filter step kept only the paths whose names end in .csv. The operating system hands back a folder's entries in no fixed order, so both parts sort them with sorted() before printing them. Run this on your own computer, next to a folder of your own, to see it work.

Further reading#

• Common I/O Tasks in Modern Java, a tutorial on dev.java
• The Files class in the Java SE 25 API documentation
• The Path interface in the Java SE 25 API documentation
• JEP 400: UTF-8 by Default, the change that made UTF-8 the default in Java 18