I/O Streams, NIO.2, and File Handling

Almost every program must read and write data outside its own memory: files on disk, data over a network, input from the console. Java's input/output facilities provide this through streams of bytes and characters, and through a modern file API, NIO.2 (the java.nio.file package introduced in Java 7), that makes file and directory operations clean and reliable. Understanding I/O is essential because the boundary between a program and the outside world is where much real work, and many bugs, live.

The classic I/O model layers streams: byte streams (InputStream, OutputStream) for raw data and character streams (Reader, Writer) for text, with buffering and other wrappers added by composition. NIO.2 adds the Path abstraction for filesystem locations and the Files utility class for high-level operations, reading all lines, copying, walking a directory tree, in single, robust calls, and integrates with try-with-resources for guaranteed closing.

Understanding I/O and NIO.2 matters because file and stream handling is pervasive and error-prone: resources must be closed to avoid leaks, character encodings must be handled correctly to avoid corruption, and large files must be processed without exhausting memory. Knowing the stream model, the modern Files and Path API, and the patterns that make I/O safe equips you to move data in and out of programs correctly and efficiently.

Analogy🏏Cricket

🏏 Think of it like cricket: a team sheet does not just list players, it assigns each to a precise, declared role, opener, spinner, wicketkeeper, and the laws and the captain enforce that a player operates within their declared role: you cannot send a designated bowler to keep wicket without an official change. Just as each player's role is fixed and checked before play, each Java variable's type is fixed at compile time and checked by the compiler. Just as trying to use a player outside their role is caught by the officials before it disrupts the match, using a variable in a type-incompatible way is caught by the compiler before the program runs. Just as clear role assignments prevent on-field confusion, clear type declarations prevent runtime errors. The insight is that declaring and enforcing roles up front, for players or for data, catches mistakes early rather than mid-match.