I/O und Datei-Handling.

Sobald dein Programm mit der Außenwelt redet, eine Datei liest, eine schreibt, übers Netzwerk kommuniziert, läuft das über Streams: einen Fluss von Daten, der Stück für Stück gelesen oder geschrieben wird. Java trennt dabei sauber zwischen Byte-Strömen (für Binärdaten) und Zeichen-Strömen (für Text). Wer das verwechselt, bekommt kaputte Umlaute oder unnötig komplizierten Code.

Was du können musst:

• Byte-Streams (InputStream/OutputStream) von Char-Streams (Reader/Writer) unterscheiden
• das Lese-Muster mit dem EOF-Signal kennen (read() liefert -1, readLine() liefert null)
• Buffering verstehen (warum BufferedReader schneller ist)
• Dateien sicher schließen (try-with-resources) und das richtige Encoding (UTF-8) wählen

Abgrenzung: hier die Grundlagen der Datei-I/O. Tiefes NIO (Channels, Buffers, Memory-Mapped Files, asynchrones I/O) ist Vertiefung.

Die Idee in einem Satz

Ein Stream ist ein Datenfluss: InputStream/Reader liest Daten herein, OutputStream/Writer schreibt hinaus, Stück für Stück, bis das Ende (EOF) erreicht ist.

Byte-Streams vs. Char-Streams

Faustregel: Text → Char-Stream (Reader/Writer), alles andere → Byte-Stream. Ein Char-Stream wandelt Bytes über ein Encoding (Charset, meist UTF-8) in Zeichen um; ein Byte-Stream tut das nicht.

// Byte-Stream: Datei roh als Bytes lesen
try (InputStream in = new FileInputStream("bild.png")) {
    int b;
    while ((b = in.read()) != -1) { /* b ist ein Byte 0-255 */ }
}

// Char-Stream: Textdatei zeilenweise lesen (mit Encoding)
try (BufferedReader br = Files.newBufferedReader(Path.of("text.txt"))) {
    String zeile;
    while ((zeile = br.readLine()) != null) { System.out.println(zeile); }
}

Das Lese-Muster und das EOF-Signal

Das häufigste Klausur-Detail: woran erkennt die Schleife das Dateiende? Bei einem Byte-Stream liefert read() einen int zurück, das gelesene Byte (0 bis 255) oder -1, wenn nichts mehr kommt. -1, nicht 0, denn 0 ist ein gültiges Byte. Verfolge den Lese-Loop:

Buffering: warum BufferedReader

Jeder ungepufferte read() löst potenziell einen Festplatten-Zugriff (System-Call) aus, byteweise ist das extrem langsam. Ein Buffer liest einen großen Block auf einmal in den Speicher; die folgenden read()-Aufrufe werden dann aus dem RAM bedient.

Moderne I/O: NIO (Files / Path)

Für die meisten Fälle reicht heute die knappe NIO-API aus java.nio.file:

// ganze Datei als String (kleine Dateien)
String inhalt = Files.readString(Path.of("text.txt"));        // UTF-8

// alle Zeilen als Liste
List<String> zeilen = Files.readAllLines(Path.of("text.txt"));

// schreiben
Files.writeString(Path.of("out.txt"), "Hallo");

// gepufferter Reader (grosse Dateien, zeilenweise)
try (BufferedReader br = Files.newBufferedReader(Path.of("gross.txt"))) { ... }

Files.readString / readAllLines laden die ganze Datei in den Speicher, ideal für kleine Dateien. Für große Dateien zeilenweise mit BufferedReader streamen.

Klausur-Faustregeln

1. Text → Char-Stream, Binär → Byte-Stream. Reader/Writer für .txt/.csv/.json, InputStream/OutputStream für Bilder, Audio, serialisierte Objekte.

2. EOF-Signale auseinanderhalten. Byte-read() liefert -1 am Ende, readLine() liefert null. Beides ist nicht 0 und nicht "" (leerer String).

3. Immer puffern. BufferedReader/BufferedInputStream macht aus vielen kleinen Festplatten-Zugriffen wenige große, oft drastisch schneller.

4. Encoding explizit setzen. Char-Streams wandeln Bytes über ein Charset (UTF-8). Ohne Angabe greift der Plattform-Default, das ist nicht portabel und zerschießt Umlaute.

5. Ressourcen mit try-with-resources schließen. Datei/Stream schließen, auch im Fehlerfall, sonst Resource-Leak.

6. NIO (Files/Path) für knappe Standard-Fälle. Files.readString, Files.readAllLines, Files.writeString ersetzen viel altes Boilerplate.

Häufige Stolpersteine

1. EOF-Bedingung falsch. while (in.read() != 0) statt != -1 läuft ewig oder bricht beim ersten Null-Byte ab. Bei readLine() ist die Bedingung != null, sonst NullPointerException.

2. Byte-Stream für Text. Direkt Bytes lesen und in chars casten ignoriert das Encoding, Mehrbyte-Zeichen (ä, ö, ü, Emojis) zerbrechen. Für Text immer Reader/Writer.

3. Nicht puffern. Byteweise von der Platte lesen ohne Buffer ist um Größenordnungen langsamer. Im Zweifel BufferedReader drumherum.

4. Datei nicht geschlossen. Ohne close() (oder try-with-resources) bleibt der File-Handle offen, Resource-Leak, bei vielen offenen Dateien "too many open files".

5. Encoding nicht angegeben. new FileReader(...) nutzt den Plattform-Default. Besser Files.newBufferedReader(path) (UTF-8) oder das Charset explizit angeben.

6. read() liefert int, nicht byte. Wer den Rückgabewert vorschnell in byte castet, kann -1 (EOF) nicht mehr von 255 unterscheiden. Erst auf -1 prüfen, dann casten.

Eine Textdatei zeilenweise lesen

Der Standard-Weg, eine Textdatei zu verarbeiten: gepufferter Reader, Zeile für Zeile, bis readLine() null liefert, und automatisch geschlossen per try-with-resources. Achte im Stepper auf das null-Signal (das Char-Pendant zum -1 der Byte-Streams).

Klausur-Tipp: Zwei Fragen kommen fast immer: (1) "Wie erkennt die Schleife das Dateiende?" Antwort: read() → -1, readLine() → null. (2) "Warum BufferedReader?" Antwort: weniger Festplatten-Zugriffe (Buffer statt byteweise). Und: nenne try-with-resources fürs sichere Schließen.