When a production log file is corrupted, I often need the smallest possible tool to inspect the raw bytes without pulling in a heavy parser. I reach for FileReader.read() because it exposes the simplest contract: one character at a time, no hidden buffering semantics to guess about, and a clear end-of-stream signal. That tiny API surface makes it ideal for debugging, teaching, and certain low-volume pipelines where clarity is worth more than peak throughput.
You’re about to work through the read() method from the ground up: what it returns, why it returns an int, how to handle end-of-stream safely, and where FileReader fits in a modern Java stack. I’ll show runnable examples, highlight common mistakes I still see in code reviews, and give you practical guidance on when to choose FileReader versus buffered or NIO alternatives. By the end, you should be able to read files character-by-character with confidence, avoid subtle Unicode pitfalls, and make a reasoned call about whether this classic API is the right tool for your next task.
The Read Contract: One Character as an Int
FileReader.read() returns a single character as an int. The int is the numeric value of the UTF-16 code unit read, and it sits in the range 0 to 65535. The special value -1 indicates end-of-stream. I treat that range as the most important behavioral rule: if you ignore the -1, you’ll either loop forever or print garbage, and if you cast before checking, you can silently turn -1 into a valid character.
The signature is short, but the behavior is precise:
public abstract int read()
That wording means:
- You get one character at a time.
- You must check for -1 before using the value.
- The value is not a byte. It’s a UTF-16 code unit, which matters for non-BMP characters.
The API is small on purpose. It mirrors the underlying Reader contract and lets you build your own parsing behavior on top. Think of it like a turnstile: every call lets exactly one character through. That predictability is why I still keep it in my toolbox, even in 2026 when most of my file IO is buffered or NIO-based.
Why It Returns int, Not char
I often hear “Why not return char?” The answer is the end-of-stream marker. A char can’t represent -1, so read() needs a wider type. If you treat the int as a char too early, you can corrupt your control flow.
Here’s the safe pattern I recommend:
import java.io.FileReader;
import java.io.IOException;
public class ReadSingleCharDemo {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/invoice.txt")) {
int value = reader.read();
if (value != -1) {
char ch = (char) value;
System.out.println("First character: " + ch);
} else {
System.out.println("File is empty");
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
Notice that I only cast after checking for -1. That one line prevents a surprising class of bugs where empty files produce a weird character output. In code reviews, this is the single most common error I see with read(): casting too soon.
Example 1: Read Exactly One Character
Sometimes you need exactly one character—no more. This can happen when you’re checking a signature or detecting a delimiter before choosing a parsing path. In those cases, calling read() once is ideal.
import java.io.FileReader;
import java.io.IOException;
public class ReadFirstCharacter {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/header.txt")) {
int next = reader.read();
if (next == -1) {
System.out.println("No content to read");
return;
}
char first = (char) next;
System.out.println("Header starts with: " + first);
} catch (IOException e) {
System.err.println("IO error: " + e.getMessage());
}
}
}
This is the simplest usage pattern and the best way to teach the API. You can also reuse that one character by storing it and continuing with a loop if your parsing logic needs it.
Example 2: Read the Entire File, One Character at a Time
If you want to read all characters, you loop until read() returns -1. This is the standard pattern and the one you should default to when teaching or debugging.
import java.io.FileReader;
import java.io.IOException;
public class ReadAllCharacters {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/notes.txt")) {
int value;
while ((value = reader.read()) != -1) {
System.out.print((char) value);
}
} catch (IOException e) {
System.err.println("Could not read file: " + e.getMessage());
}
}
}
I like to keep the loop compact and readable. The assignment inside the while condition is idiomatic Java and keeps state in one place. If you’re writing for a junior team, add a short comment about the loop condition to avoid confusion.
Character Encoding: What FileReader Really Uses
FileReader uses the platform’s default charset unless you choose a constructor that explicitly specifies a charset (available through InputStreamReader or FileReader constructors in newer JDKs). This default can be different between machines. That difference matters when your file has non-ASCII characters.
Here’s the practical risk: a file that reads correctly on your laptop can break on a server with a different default charset. I see this when teams test on macOS but deploy to Linux with a different default. If you know the file encoding, you should pin it.
Use InputStreamReader when you need explicit charset control:
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.io.BufferedReader;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
public class ReadWithCharset {
public static void main(String[] args) {
try (BufferedReader reader = new BufferedReader(
new InputStreamReader(
new FileInputStream("data/customers.csv"),
StandardCharsets.UTF_8))) {
int value;
while ((value = reader.read()) != -1) {
System.out.print((char) value);
}
} catch (IOException e) {
System.err.println("Error: " + e.getMessage());
}
}
}
I prefer this pattern in production because it’s explicit and predictable. If you still want FileReader ergonomics, newer JDKs let you supply a Charset directly to FileReader. When writing code that will live longer than a single environment, explicit charset selection is the safer path.
Unicode Edge Cases: Surrogate Pairs and Emoji
read() returns a UTF-16 code unit, not a Unicode code point. That distinction matters for characters outside the Basic Multilingual Plane, such as emoji or some CJK extensions. These require two code units (a surrogate pair).
If you read one code unit at a time, you can split a single visual character into two values. That is correct behavior for read(), but you need to handle it if you are counting characters or doing text analysis.
If your task is Unicode-aware, I recommend converting to code points:
import java.io.FileReader;
import java.io.IOException;
public class ReadCodePoints {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/emoji.txt")) {
int first;
while ((first = reader.read()) != -1) {
char ch1 = (char) first;
if (Character.isHighSurrogate(ch1)) {
int second = reader.read();
if (second != -1) {
char ch2 = (char) second;
int codePoint = Character.toCodePoint(ch1, ch2);
System.out.print(new String(Character.toChars(codePoint)));
}
} else {
System.out.print(ch1);
}
}
} catch (IOException e) {
System.err.println("Error: " + e.getMessage());
}
}
}
This is overkill for many files, but I’ve used it in logging tools and data importers where emoji or uncommon scripts appear. If your files are guaranteed ASCII or Latin-1, you can ignore this; otherwise, keep it in mind when you do any character counting or validation.
When FileReader Is the Right Tool (and When It’s Not)
I like FileReader.read() for clarity, diagnostics, and tiny utilities. I avoid it for large files or anything performance-sensitive. It is simple, but it isn’t fast because it performs one character read at a time and can trigger many underlying reads.
Here’s the guidance I use:
Use FileReader.read() when:
- You want to inspect raw file content and keep the code tiny.
- You need a deterministic, character-level parsing loop.
- The file is small (think under a few megabytes).
- You’re teaching or debugging and want minimal abstraction.
Avoid FileReader.read() when:
- The file is large or you need throughput.
- You will parse line-by-line or with complex tokenization.
- You need precise control of buffering or read-ahead.
If you need speed, wrap it in a BufferedReader or switch to NIO. That small change can cut wall time dramatically for large files. I’ve seen single-digit milliseconds per megabyte with buffered reads in JVMs tuned for server workloads, whereas unbuffered read() loops can climb into tens of milliseconds per megabyte under heavy load. Those numbers depend on disk, OS cache, and JVM settings, but the trend is consistent.
BufferedReader vs FileReader: A Quick Comparison
When you move from FileReader to BufferedReader, you still use read() but you gain buffering. That means fewer system calls and better throughput. In practice, it’s one of the easiest performance wins in Java IO.
Here’s a side-by-side table to help you choose:
Traditional FileReader.read()
—
Best choice for clarity
Slow; too many reads
Default charset might surprise you
Manual loop and string building
Small snippets are easy to generate
My default in production is BufferedReader with a charset, unless I need the raw, single-character semantics for a parser. If you’re using AI-assisted coding tools, you’ll notice that modern templates already prefer buffered IO; follow that direction unless you have a strong reason to keep it unbuffered.
Common Mistakes I See (and How to Avoid Them)
Here are the patterns I still fix in code reviews:
1) Casting before checking -1
Wrong:
char ch = (char) reader.read();
Right:
int value = reader.read();
if (value != -1) {
char ch = (char) value;
}
2) Forgetting to close the reader
Always use try-with-resources. It closes even if exceptions happen.
3) Ignoring charset issues
If the file isn’t guaranteed to be in the platform default encoding, use an explicit charset.
4) Reading in a loop without buffering
For anything bigger than a small file, wrap in BufferedReader or use NIO.
5) Counting characters incorrectly with Unicode
If your file contains emoji or uncommon scripts, remember that read() returns UTF-16 code units, not code points.
Each of these bugs is easy to avoid once you know why the API is shaped the way it is. I recommend a quick team guideline: “Always check for -1 before casting.” That single rule eliminates most issues.
A Practical Pattern: Parsing a Delimited Record
To show how read() helps with precise parsing, here’s a simple parser that reads until it hits a delimiter. This is useful in legacy formats or when you need to handle delimiters that may appear in other IO methods’ buffering behavior.
import java.io.FileReader;
import java.io.IOException;
public class ReadUntilDelimiter {
public static void main(String[] args) {
StringBuilder token = new StringBuilder();
char delimiter = ‘|‘;
try (FileReader reader = new FileReader("data/records.txt")) {
int value;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (ch == delimiter) {
System.out.println("Token: " + token);
token.setLength(0);
} else {
token.append(ch);
}
}
if (token.length() > 0) {
System.out.println("Token: " + token);
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This is intentionally low-level, but it’s precise. You control every character, which can be critical when you’re dealing with messy input that line-based readers can’t reliably parse. I still use this approach for custom formats and legacy imports.
Performance Notes: What to Expect
FileReader.read() is simple, but performance depends heavily on buffering and disk conditions. For tiny files, it’s perfectly fine. For multi-megabyte logs, the difference between buffered and unbuffered read() can be large.
In real projects, I see these rough ranges:
- Unbuffered read() across large files: typically 20–60 ms per MB on a busy dev laptop.
- BufferedReader with read(): typically 5–15 ms per MB on the same hardware.
- NIO with larger buffers: can drop further, often 2–8 ms per MB depending on the JVM and IO stack.
These are not promises, just ballpark observations. You should test on your own hardware if throughput matters. But the trend is consistent: buffering reduces system calls and speeds things up.
If you need to keep the API but boost speed, wrap FileReader in BufferedReader and keep the same loop structure. You get speed without changing your parsing logic.
Modern Workflow Tips (2026)
Even when I’m working with AI-assisted coding tools, I keep FileReader.read() in my mental model because it’s a useful baseline for teaching and for building custom parsers. A few habits help me avoid mistakes:
- I keep a tiny template snippet that uses try-with-resources and checks -1 before casting.
- I always decide on charset up front; default charset only for quick scripts.
- I add a one-line comment if the loop structure is complex or handles surrogate pairs.
- I treat FileReader as a surgical tool, not a general-purpose file loader.
This approach fits the way most teams operate in 2026: fast iterations with tooling, but a respect for low-level IO when you need control.
Example 3: Read a File and Count Specific Characters
A common real-world use case is counting characters—maybe to detect how many commas are present in a CSV or to measure punctuation frequency. With read(), you can do that in a straightforward loop.
import java.io.FileReader;
import java.io.IOException;
public class CountCommas {
public static void main(String[] args) {
int commas = 0;
try (FileReader reader = new FileReader("data/export.csv")) {
int value;
while ((value = reader.read()) != -1) {
if ((char) value == ‘,‘) {
commas++;
}
}
System.out.println("Comma count: " + commas);
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This might look trivial, but it’s reliable. When you need a small utility, it’s hard to beat this clarity. If you care about Unicode-aware counts, you’d pivot to code points instead, but for ASCII punctuation it’s ideal.
Example 4: Detecting File Encoding Heuristically
Sometimes you don’t control the input file and you’re forced to guess. read() can help you sniff for a UTF-8 BOM or other markers before you hand the stream to a heavier parser. This is a lightweight guardrail.
import java.io.FileInputStream;
import java.io.IOException;
public class DetectUtf8Bom {
public static void main(String[] args) {
try (FileInputStream in = new FileInputStream("data/unknown.txt")) {
int b1 = in.read();
int b2 = in.read();
int b3 = in.read();
boolean hasUtf8Bom = (b1 == 0xEF && b2 == 0xBB && b3 == 0xBF);
System.out.println("UTF-8 BOM detected: " + hasUtf8Bom);
} catch (IOException e) {
System.err.println("Error: " + e.getMessage());
}
}
}
This example uses FileInputStream because a BOM is byte-level, not character-level. I like to show it alongside FileReader usage because it clarifies what FileReader does and does not expose. The takeaway: FileReader is for characters, but sometimes you need a byte-level peek first.
Example 5: Read and Build Lines Manually
You don’t need BufferedReader to read lines, but you should understand how lines are assembled if you ever parse manually. It’s useful for custom line endings or formats that don’t follow the standard \n or \r\n conventions.
import java.io.FileReader;
import java.io.IOException;
public class ManualLineReader {
public static void main(String[] args) {
StringBuilder line = new StringBuilder();
try (FileReader reader = new FileReader("data/legacy.txt")) {
int value;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (ch == ‘\n‘) {
System.out.println("Line: " + line);
line.setLength(0);
} else if (ch != ‘\r‘) {
line.append(ch);
}
}
if (line.length() > 0) {
System.out.println("Line: " + line);
}
} catch (IOException e) {
System.err.println("Error: " + e.getMessage());
}
}
}
This is exactly what BufferedReader.readLine() does for you, but seeing it makes the mechanics obvious. It also gives you a place to handle weird line separators or embedded nulls that might confuse high-level readers.
Example 6: Skipping a Prefix Then Parsing
I often read the first few characters to detect a header or version marker, then continue with a different parser. Here’s a small pattern I’ve used in file format detectors.
import java.io.FileReader;
import java.io.IOException;
public class DetectPrefix {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/mixed-format.txt")) {
StringBuilder prefix = new StringBuilder();
int value;
for (int i = 0; i < 4; i++) {
value = reader.read();
if (value == -1) {
break;
}
prefix.append((char) value);
}
if ("LOG:".contentEquals(prefix)) {
System.out.println("Detected log format");
} else if ("CSV,".contentEquals(prefix)) {
System.out.println("Detected CSV format");
} else {
System.out.println("Unknown prefix: " + prefix);
}
// Continue reading after the prefix if needed...
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This is a tiny example, but it shows how you can treat FileReader.read() as a building block for format detection or conditional parsing.
Edge Cases You Should Know About
There are a few less obvious behaviors I keep in mind when I use read(). They’re not hard, but they’re easy to forget if you only use high-level readers.
- Empty files return -1 immediately. Always handle this explicitly if you expect to read at least one character.
- Some files contain null characters (\u0000). read() will return 0 in that case, which is a valid character and not an end-of-stream signal.
- If a file ends with a high surrogate and no low surrogate, you’ll get a dangling surrogate. That might be a corrupt or truncated file, and your code should decide how to handle it.
- If you mix read() with other reader methods that buffer internally, the read position can be hard to reason about. Stick with one reading strategy for a single stream.
I usually add a small validation path for corrupted files: if I detect a dangling surrogate, I log a warning and either skip it or replace it with a placeholder. It’s not about being perfect; it’s about being deliberate.
Handling Errors Gracefully
Most examples show a simple catch block that prints the exception. That’s fine for demos, but in production I want structured error handling.
A few practical tips:
- Use a custom error message that includes the file path.
- Differentiate between “file not found” and “read error” if you can.
- If you’re in a batch process, keep reading other files instead of failing the whole job.
Here’s a simple enhancement pattern:
import java.io.FileReader;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
public class SafeRead {
public static void main(String[] args) {
Path path = Path.of("data/critical.txt");
if (!Files.exists(path)) {
System.err.println("Missing file: " + path);
return;
}
try (FileReader reader = new FileReader(path.toFile())) {
int value;
while ((value = reader.read()) != -1) {
System.out.print((char) value);
}
} catch (IOException e) {
System.err.println("Read error for " + path + ": " + e.getMessage());
}
}
}
This doesn’t add much complexity but makes failure modes more understandable for the person on call at 2 a.m.
Practical Scenario: Inspecting a Corrupted Log File
I started this draft with a corrupted log file because it’s a situation where FileReader.read() shines. You don’t want a heavyweight parser that may explode on invalid input. You want to stream the file char-by-char and stop when you find the bad region.
I’ll often add a small index counter and print the character codes to locate where the corruption starts:
import java.io.FileReader;
import java.io.IOException;
public class InspectCorruption {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/app.log")) {
int value;
long index = 0;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (ch == ‘\u0000‘) {
System.out.println("Null char at index " + index);
break;
}
index++;
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This style is fast to write and gives you just enough data to decide whether to salvage the file or discard it.
Practical Scenario: Minimal Tokenizer for Legacy Format
Sometimes you can’t use CSV or JSON libraries because the format is half-structured and full of quirks. A character-level tokenizer lets you define exactly what counts as a token.
import java.io.FileReader;
import java.io.IOException;
public class LegacyTokenizer {
public static void main(String[] args) {
char delimiter = ‘;‘;
boolean inQuotes = false;
StringBuilder token = new StringBuilder();
try (FileReader reader = new FileReader("data/legacy.dat")) {
int value;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (ch == ‘"‘) {
inQuotes = !inQuotes;
continue;
}
if (!inQuotes && ch == delimiter) {
System.out.println("Token: " + token);
token.setLength(0);
} else {
token.append(ch);
}
}
if (token.length() > 0) {
System.out.println("Token: " + token);
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This doesn’t replace a real CSV library, but it’s often enough to extract a few fields from a problematic export. FileReader.read() makes it easy to implement without any extra layers.
Practical Scenario: Checking for Trailing Whitespace
Trailing whitespace in configuration files can cause subtle errors. A quick character-level scan can detect the exact lines that contain it.
import java.io.FileReader;
import java.io.IOException;
public class TrailingWhitespaceScanner {
public static void main(String[] args) {
try (FileReader reader = new FileReader("data/config.ini")) {
int value;
int line = 1;
boolean sawNonWhitespace = false;
boolean trailingWhitespace = false;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (ch == ‘\n‘) {
if (trailingWhitespace) {
System.out.println("Trailing whitespace on line " + line);
}
line++;
sawNonWhitespace = false;
trailingWhitespace = false;
} else if (ch == ‘ ‘ || ch == ‘\t‘) {
if (sawNonWhitespace) {
trailingWhitespace = true;
}
} else if (ch != ‘\r‘) {
sawNonWhitespace = true;
trailingWhitespace = false;
}
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This is a good example of the kind of tiny maintenance tool that doesn’t deserve an entire parsing library. Character-level scanning is enough.
Alternative Approaches and Why You Might Choose Them
FileReader.read() is not the only game in town. It’s important to understand alternatives so you can choose intentionally.
- BufferedReader: Adds buffering and conveniences like readLine(). It’s the first upgrade I make when performance matters.
- InputStreamReader: Lets you specify a charset for any InputStream. This is the foundation of most robust text reading in Java.
- Files.newBufferedReader: Modern, concise, and supports charset. It’s a good default for new code.
- NIO (Files.readAllBytes or FileChannel): Better for large files or when you need precise control over buffers and performance.
I still reach for FileReader when the task is small, the encoding is known or irrelevant, and I want the smallest possible code path. But for most production code, I’ll pivot to a buffered reader or NIO.
A Short Comparison Table: FileReader vs NIO
Sometimes it’s easier to see the choice in a simplified view:
Best Fit
—
FileReader.read()
NIO FileChannel or BufferedReader
InputStreamReader or Files.newBufferedReader
FileChannel with ByteBuffer
BufferedReader or streaming parserThis isn’t a rulebook. It’s a quick map I keep in my head to avoid over-engineering.
Testing and Validation Strategies
Even simple IO code benefits from a small validation checklist. Here’s what I typically verify:
- Test with an empty file to confirm -1 handling.
- Test with ASCII text to confirm baseline output.
- Test with Unicode (emoji or non-Latin scripts) to see whether surrogate pairs appear.
- Test with a file that ends without a newline if you do manual line reading.
- Test with a file that contains null characters if you handle binary-ish logs.
These tests are quick to set up and save time later when you move the code between machines or environments.
Logging and Observability in Production
If you end up using a FileReader.read() loop in a production pipeline, add a little instrumentation. Nothing heavy—just enough to debug.
A few things I log:
- File path and size before reading.
- Character count or line count at the end.
- A warning if a malformed surrogate pair appears.
- Time taken to read and process.
This is especially helpful for batch jobs where you might need to identify slow files or corrupted inputs without re-running the whole pipeline.
Security and Safety Considerations
This is rarely mentioned for such a small API, but it’s worth saying:
- Don’t assume text files are safe. If you pass characters directly into another system, you might need sanitization.
- Avoid reading untrusted files into memory all at once. FileReader.read() naturally streams, which is good.
- If you parse user-controlled input, guard against overly large files or extremely long tokens that could lead to memory pressure.
FileReader.read() helps with streaming and avoids accidental memory spikes, but you still need to be cautious about how you accumulate data in StringBuilder or lists.
Realistic Pattern: Stream and Accumulate in Chunks
Even when you’re reading character-by-character, you can still process data in chunks to keep memory predictable. Here’s a pattern I use for a simple word counter:
import java.io.FileReader;
import java.io.IOException;
public class WordCounter {
public static void main(String[] args) {
int words = 0;
boolean inWord = false;
try (FileReader reader = new FileReader("data/book.txt")) {
int value;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (Character.isWhitespace(ch)) {
if (inWord) {
words++;
inWord = false;
}
} else {
inWord = true;
}
}
if (inWord) {
words++;
}
System.out.println("Word count: " + words);
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This example is basic, but it demonstrates how you can build accurate streaming logic without holding the whole file in memory.
Example 7: Simple Stateful Parser with Escape Characters
If you need to interpret escape sequences (like backslash-escaped delimiters), a character-level loop is often the most straightforward solution.
import java.io.FileReader;
import java.io.IOException;
public class EscapedDelimiterParser {
public static void main(String[] args) {
char delimiter = ‘,‘;
StringBuilder token = new StringBuilder();
boolean escape = false;
try (FileReader reader = new FileReader("data/escaped.csv")) {
int value;
while ((value = reader.read()) != -1) {
char ch = (char) value;
if (escape) {
token.append(ch);
escape = false;
} else if (ch == ‘\\‘) {
escape = true;
} else if (ch == delimiter) {
System.out.println("Token: " + token);
token.setLength(0);
} else {
token.append(ch);
}
}
if (token.length() > 0) {
System.out.println("Token: " + token);
}
} catch (IOException e) {
System.err.println("Read failed: " + e.getMessage());
}
}
}
This is the kind of parser that becomes difficult with line-based APIs, especially when the delimiters appear inside escaped sequences.
Practical Guidance: Choosing the Smallest Correct Tool
In a modern Java stack, I usually start with Files.newBufferedReader and a specified charset. But I still keep FileReader in reach for three reasons:
- It forces me to be explicit about stream control.
- It’s easy to teach and easy to debug.
- It gives me a clean base for custom parsers or scanners.
If I’m building something that will live for years or handle large datasets, I move to buffered or NIO options early. If I’m writing a tiny tool for a one-off task, FileReader.read() is often perfect.
Summary: The Short Checklist I Use
Before I decide to use FileReader.read(), I ask myself:
- Do I truly need character-level control?
- Is the file small enough that unbuffered reading won’t hurt?
- Is the charset known, and do I need to be explicit about it?
- Do I need Unicode-aware code points instead of UTF-16 code units?
- Will this code live beyond a one-off script?
If the answers are aligned with simplicity and control, FileReader.read() is a good choice. If not, I pivot to a buffered or NIO solution.
Final Thoughts
The read() method is a tiny API with a surprisingly rich set of implications: end-of-stream handling, charset decisions, Unicode nuances, and performance trade-offs. Once you understand those details, you can use FileReader.read() with confidence and avoid the subtle bugs that show up when you treat it like a byte reader or forget the -1 rule.
I keep it in my toolbox not because it’s the fastest, but because it’s honest. It does exactly what it says: one character at a time. That makes it a reliable baseline for teaching, debugging, and low-level parsing—especially when I need to reason about every character flowing through my code.
