Standard Input and Output in Java

Reading input and printing output are among the first things nearly every program does. A program asks a user for a value, works with it, and reports a result. The standard Java tools for these jobs can feel clumsy to a beginner. The TextIO class exists to make these tasks easier.

Because TextIO looks like a convenient helper, it is tempting to assume it will behave the same way no matter where the program runs. That assumption is the one this article examines. The source material shows that it is not quite true, and the reason tells you something important about how standard input and output depend on their surroundings.

A package is a grouping of related classes. The TextIO class belongs to the textio package, so a program that uses it refers to that package to find the class. Because TextIO's methods are static, they are called on the class itself rather than on an object you create first. This is the reason TextIO can be used as a simple utility: you call its input and output methods directly.

The easiest way to understand TextIO is to picture it as a middle layer between a program and the places its data comes from and goes to. Input can arrive from standard input or from other sources such as files. The program receives those values through TextIO's input methods, works with them, and then sends results back out through TextIO's output methods to standard output or to other destinations.

Follow one value through the path. Text typed by the user enters through standard input, which is the stream called System.in. TextIO's input methods take that text in. The program then stores it in a variable and uses it. When the program prints a result, TextIO's output methods send that text out to standard output, the stream called System.out, which is where it appears on the screen.

The main purpose of TextIO is to make the standard input stream, System.in, easier to use. It also provides methods for printing to System.out. Every command-line Java program uses these two standard streams, and TextIO wraps them so that reading a value from the user and printing a result requires less effort.

TextIO is not limited to the standard streams. The source states that it also supports other input sources and output destinations, such as files. This means the same family of TextIO methods can be pointed at a file instead of the keyboard or the screen. The program's logic for working with the values does not have to change just because the source or destination changed.

Only the source end of the path changes when you switch from System.in to a file: the values now come from the file rather than from the keyboard, and the program receives them through the same kind of TextIO input call. The source does not describe the exact file-handling steps, so the practical details should be checked in the TextIO material itself.

The central point of this article is that TextIO's behavior depends on where the program runs. The source describes the class as useful in a command-line environment. It also says that integrated development environments such as Eclipse are places where standard input does not work particularly well, and that TextIO might be inconvenient to use there.

Because the environment changes how standard input and output behave, the same TextIO code can produce a different experience. The source does not give the detailed reason, so treat the difference as the documented behavior: TextIO is tied to the command-line setting, and an IDE console may be a less comfortable place to use it. The source points to another file as an alternative for that situation, although it does not name that file in the material provided.