Input and Output Readers and Writers in Java

Imagine a program that computes an answer but has no way to receive a number from a user, show a result on a screen, or save anything for later. However clever its internal logic, nobody can use it. Programs become useful only when they can exchange information with the world around them.

This exchange is called input and output, usually shortened to I/O. Input is information arriving at the program. Output is information leaving it. Every useful program, from a small calculator to a large server, depends on I/O in some form.

A computer can be connected to many different kinds of input and output devices. Each kind may behave differently. If a programming language handled every device as its own special case, the amount of complexity would quickly become overwhelming. The source notes that designing good facilities for input and output has historically been one of the hardest parts of programming language design.

Consider what a program would need to know if it had to handle each device directly: the particular way a keyboard reports keystrokes, the way a disk stores bytes in a location, and the way a network connection delivers data. Writing separate logic for every one of these would tie the program tightly to hardware details.

I/O abstractions let a language handle many device types without treating each as a special case. Once the program talks to a common representation, the same kind of read or write request can be used whether the other end is a keyboard, a file, or a network connection. The details of each device are handled behind that representation.

Because each stream has a direction, you can trace how data moves through a program. Input flows from a device, through an input stream, into the program. Output flows the other way: from the program, through an output stream, to a device. The program sits at the center because it is the party that consumes input and produces output.

Read the diagram as two paths sharing one program. The upper path carries input inward, and the lower path carries output outward. The same program can have both kinds of path at once, and each path is governed by the direction of its own stream.

The main benefit of the stream abstraction is that the program's logic can stay the same while the source or destination changes. The diagram below shows a single program connected to input and output streams, and each stream connected to a different kind of endpoint.

Notice that the program talks to a stream, not to the keyboard or the file directly. Whichever endpoint sits behind the stream, the program's side of the exchange is expressed in the same terms: read from an input stream, or write to an output stream.

Streams are not the only I/O abstraction. Files and channels also exist, and they serve the same general purpose: simplifying work with different kinds of devices. The source states that it will concentrate only on streams in this section, so the remainder of this article treats streams as the focus while acknowledging the other abstractions around them.

The concept map places streams, files, and channels side by side as different I/O abstractions. Each is a way of working with devices without treating every device as a special case. The source does not describe the internal relationship between files and channels in detail, so this article does not make claims beyond the fact that both are I/O abstractions alongside streams.