7Datenströme 
»Wer zur Quelle will, muss gegen den Strom schwimmen.«
– Danny Kaye (1913–1987)
Um an die Information einer Datei oder an andere Ressourcen zu gelangen, müssen wir den Inhalt auslesen können. Das geht für Dateien mit einer Klasse wie RandomAccessFile, allerdings funktioniert so etwas nicht bei Daten, die etwa aus dem Internet kommen, denn hier gibt es keinen wahlfreien Zugriff. Hier rückt ein anderes Konzept in den Mittelpunkt: der Datenstrom (engl. stream). Dieser entsteht beim Fluss der Daten von der Eingabe über die Verarbeitung hin zur Ausgabe. Mittels Datenströmen können Daten sehr elegant bewegt werden; ein Programm ohne Datenfluss ist eigentlich undenkbar. Die Eingabeströme (engl. input streams) sind zum Beispiel Daten der Tastatur oder vom Netzwerk; über die Ausgabeströme (engl. output streams) fließen die Daten in ein Ausgabemedium, beispielsweise in den Drucker oder in eine Datei. Die Kommunikation der Threads erfolgt über Pipes.
In Java sind über 30 Klassen zur Verarbeitung der Datenströme vorgesehen. Da die Datenströme an kein spezielles Ein- oder Ausgabeobjekt gebunden sind, können sie beliebig miteinander gemischt werden. Dies ist mit dem elektrischen Strom vergleichbar: Es gibt mehrere Stromlieferanten (Solarkraftwerke, Nutzung geothermischer Energie, Umwandlung von Meereswärmeenergie [OTEC]) und mehrere Verbraucher (Wärmedecke, Mikrowelle), die die Energie wieder umsetzen.
7.1Stream-Klassen für Bytes und Zeichen
Unterschiedliche Klassen zum Lesen und Schreiben von Binär- und Zeichendaten sammeln sich im Paket java.io. Für die byteorientierte Verarbeitung, etwa von PDF- oder MP3-Dateien, gibt es andere Klassen als für Textdokumente, zum Beispiel HTML oder Konfigurationsdateien. Binär- von Zeichendaten zu trennen ist sinnvoll, da zum Beispiel beim Einlesen von Textdateien diese immer in Unicode konvertiert werden müssen, da Java intern alle Zeichen in Unicode kodiert.
Die vier Basisklassen sind:
die zeichenorientierten Klassen Reader und Writer
die byteorientierten Klassen InputStream und OutputStream
Zusammen wollen wir sie Stromklassen nennen. Hier in den Klassen sind die zu erwartenden Methoden wie read(…) und write(…) zu finden.
7.1.1Lesen aus Dateien und Schreiben in Dateien
Um Daten aus Dateien lesen oder sie schreiben zu können, ist eine Stromklasse nötig, die es schafft, die Operationen von Reader, Writer, InputStream und OutputStream auf Dateien abzubilden. Um an solche Implementierungen zu kommen, gibt es drei verschiedene Ansätze:
Die Utility-Klasse Files bietet vier newXXX(…)-Methoden, um Lese-/Schreib-Datenströme für zeichen- und byteorientierte Dateien zu bekommen.
Ein Class-Objekt bietet getResourceAsStream(…) und liefert einen InputStream, um Bytes aus Dateien im Klassenpfad zu lesen. Zum Schreiben gibt es nichts Vergleichbares. Falls Unicode-Zeichen gelesen werden sollen, muss der InputStream in einen Reader konvertiert werden.
Die speziellen Klassen FileInputStream, FileReader, FileOutputStream, FileWriter sind Stromklassen, die read(…)/write(…)-Methoden auf Dateien abbilden.
Jede der Varianten hat Vor- und Nachteile. Wir wollen die einzelnen Möglichkeiten nun kennenlernen und voneinander abgrenzen.
7.1.2Byteorientierte Datenströme über Files beziehen
Die Files-Klasse bietet Methoden, die direkt den Eingabe-/Ausgabestrom liefern. Beginnen wir mit den byteorientierten Stream-Klassen:
static OutputStream newOutputStream(Path path, OpenOption... options)
throws IOException
Legt eine Datei an und liefert den Ausgabestrom auf die Datei.static InputStream newInputStream(Path path, OpenOption... options)
throws IOException
Öffnet die Datei und liefert einen Eingabestrom zum Lesen.
Da die OpenOption ein Vararg ist und somit weggelassen werden kann, ist der Programmcode kurz. (Er wäre noch kürzer ohne die korrekte Fehlerbehandlung …)
Beispiel: Eine kleine PPM-Grafikdatei schreiben
Das PPM-Format ist ein einfaches Grafikformat. Es beginnt mit einem Identifizierer, dann folgen die Ausmaße und schließlich die ARGB-Werte für die Pixelfarben.
Listing 7.1com/tutego/insel/stream/WriteTinyPPM.java, main()
out.write( "P3 1 1 255 255 0 0".getBytes( StandardCharsets.ISO_8859_1 ) );
}
catch ( IOException e ) {
e.printStackTrace();
}
7.1.3Zeichenorientierte Datenströme über Files beziehen
Neben den statischen Files-Methoden newOutputStream(…) und newInputStream(…) gibt es zwei Methoden, die zeichenorientierte Ströme liefern, also Reader/Writer:
static BufferedReader newBufferedReader(Path path, Charset cs)
throws IOExceptionstatic BufferedWriter newBufferedWriter(Path path, Charset cs, OpenOption... options)
throws IOException
Liefert einen Unicode-Zeichen lesenden Ein-/Ausgabestrom. Das Charset-Objekt bestimmt, in welcher Zeichenkodierung sich die Texte befinden, damit sie korrekt in Unicode konvertiert werden.static BufferedReader newBufferedReader(Path path)
throws IOException
Entspricht newBufferedReader(path, StandardCharsets.UTF_8). Neu in Java 8.static BufferedWriter newBufferedWriter(Path path, OpenOption... options)
throws IOException
Entspricht Files.newBufferedWriter(path, StandardCharsets.UTF_8, options). Neu in Java 8.
BufferedReader und BufferedWriter sind Unterklassen von Reader/Writer, die zum Zwecke der Optimierung Dateien im internen Puffer zwischenspeichern.
newBufferedWriter(…)
Die Rückgabe von newBufferedWriter(…) ist ein BufferedWriter, eine Unterklasse von Writer. Jeder Writer hat Methoden wie write(String), die Zeichenketten in den Strom schreiben. Die Methode soll das nächste Beispiel nutzen:
Listing 7.2com/tutego/insel/stream/NewBufferedWriterDemo.java, main()
StandardCharsets.ISO_8859_1 ) ) {
out.write( "Zwei Jäger treffen sich ..." );
out.write( System.lineSeparator() );
}
catch ( IOException e ) {
e.printStackTrace();
}
newBufferedReader()
Der BufferedReader bietet neben den einfachen geerbten Lesemethoden der Oberklasse Reader zwei weitere praktische Methoden:
String readLine(): Liest eine Zeile und liefert am Ende null, wenn die letzte Zeile erreicht wurde.
Stream<String> lines(): Liefert einen Stream von Strings. Neu in Java 8.
So einfach ist ein Programm formuliert, welches alle Zeilen einer Datei abläuft:
Listing 7.3com/tutego/insel/stream/NewBufferedReaderDemo.java, main()
StandardCharsets.ISO_8859_1 ) ) {
for ( String line; (line = in.readLine()) != null; )
System.out.println( line );
}
catch ( IOException e ) {
e.printStackTrace();
}
[zB]Beispiel
Mit der Stream-API sieht es ähnlich aus; kurz skizziert:
in.lines().forEach( System.out::println );
}
Falls es beim Lesen über den Stream zu einem Fehler kommt, wird eine RuntimeException vom Typ UncheckedIOException ausgelöst.
7.1.4Funktion von OpenOption bei den Files.newXXX(…)-Methoden
Sofern eine Datei schon existiert, wird sie beim Schreibe-Öffnen überschrieben; existiert sie nicht, wird sie neu angelegt. Diese Standardoption ist aber ein wenig zu einschränkend, und daher beschreibt OpenOption Zusatzoptionen. OpenOption ist eine Schnittstelle, die von den Aufzählungen LinkOption und StandardOpenOption realisiert wird.
OpenOption | Beschreibung |
|---|---|
java.nio.file.StandardOpenOption | |
READ | Öffnen für Lesezugriff |
WRITE | Öffnen für Schreibzugriff |
APPEND | Neue Daten kommen an das Ende. Atomar bei parallelen Schreiboperationen |
TRUNCATE_EXISTING | Für Schreiber: Existiert die Datei, wird die Länge vorher auf 0 gesetzt. |
CREATE | Legt Datei an, falls sie noch nicht existiert. |
CREATE_NEW | Legt Datei nur an, falls sie vorher noch nicht existierte. |
DELETE_ON_CLOSE | Die Java-Bibliothek versucht, die Datei zu löschen, wenn sie geschlossen wird. |
SPARSE | Hinweis für das Dateisystem, die Datei kompakt zu speichern, da sie aus vielen Null-Bytes besteht |
SYNC | Jeder Schreibzugriff und jedes Update der Metadaten soll sofort zum Dateisystem. |
DSYNC | Jeder Schreibzugriff soll sofort zum Dateisystem. |
java.nio.file.LinkOption | |
NOFOLLOW_LINKS | Symbolischen Links wird nicht gefolgt. |
Tabelle 7.1Konstanten aus StandardOpenOption und LinkOption
Die Option CREATE_NEW kann nur funktionieren, wenn die Datei noch nicht vorhanden ist. Das zeigt anschaulich das folgende Beispiel:
Listing 7.4com/tutego/insel/nio2/StandardOpenOptionCreateNewDemo.java, main()
Files.newOutputStream( Paths.get( "opa.herbert.tmp" ) ).close();
Files.newOutputStream( Paths.get( "opa.herbert.tmp" ) ).close();
Files.newOutputStream( Paths.get( "opa.herbert.tmp" ),
StandardOpenOption.CREATE_NEW ).close();
Hier führt die letzte Zeile zu einer »java.nio.file.FileAlreadyExistsException: opa.herbert.tmp«.
Die Option DELETE_ON_CLOSE ist für temporäre Dateien nützlich. Das folgende Beispiel verdeutlicht die Arbeitsweise:
Listing 7.5com/tutego/insel/nio2/StandardOpenOptionDeleteOnCloseDemo.java, main()
Files.deleteIfExists( path );
System.out.println( Files.exists( path ) ); // false
Files.newOutputStream( path ).close();
System.out.println( Files.exists( path ) ); // true
Files.newOutputStream( path, StandardOpenOption.DELETE_ON_CLOSE,
StandardOpenOption.SYNC ).close();
System.out.println( Files.exists( path ) ); // false
Im letzten Fall wird die Datei angelegt, ein Datenstrom geholt und gleich wieder geschlossen. Wegen StandardOpenOption.DELETE_ON_CLOSE wird Java die Datei von sich aus löschen, was Files.exists(Path, LinkOption...) belegt.
7.1.5Ressourcen aus dem Klassenpfad und aus JAR‐Archiven laden
Um Ressourcen wie Grafiken oder Konfigurationsdateien aus JAR-Archiven zu laden, gibt es eine Methode am Class-Objekt: getResourceAsStream(String):
implements Serializable, GenericDeclaration, Type, AnnotatedElement
InputStream getResourceAsStream(String name)
Gibt einen Eingabestrom auf die Datei mit dem Namen name zurück oder null, falls es keine Ressource mit dem Namen im Klassenpfad gibt.
Da der Klassenlader die Ressource findet, entdeckt er alle Dateien, die im Pfad des Klassenladers eingetragen sind. Das gilt auch für JAR-Archive, weil dort vom Klassenlader alles verfügbar ist. Die Methode getResourceAsStream(String) liefert auch null, wenn die Sicherheitsrichtlinien das Lesen verbieten. Da die Methode keine Ausnahme auslöst, muss auf jeden Fall getestet werden, ob die Rückgabe ungleich null war.
Das folgende Programm liest ein Byte ein und gibt es auf dem Bildschirm aus:
Listing 7.6com/tutego/insel/io/stream/GetResourceAsStreamDemo.java
import java.io.*;
import java.util.Objects;
public class GetResourceAsStreamDemo {
public static void main( String[] args ) {
String filename = "onebyte.txt";
try ( InputStream is = Objects.requireNonNull(
GetResourceAsStreamDemo.class.getResourceAsStream( filename ),
"Datei gibt es nicht!" ) ) {
System.out.println( is.read() ); // 49
}
catch ( IOException e ) {
e.printStackTrace();
}
}
}
Die Datei onebyte.txt befindet sich im gleichen Pfad wie auch die Klasse, sie liegt also in com/ tutego/insel/io/stream/onebyte.txt. Liegt sie zum Beispiel im Wurzelverzeichnis des Pakets, muss sie mit "/onebyte.txt" angegeben werden. Liegen die Ressourcen außerhalb des Klassenpfades, können sie nicht gelesen werden. Der große Vorteil ist aber, dass die Methode alle Ressourcen anzapfen kann, die über den Klassenlader zugänglich sind, und das ist insbesondere der Fall, wenn die Dateien aus JAR-Archiven kommen – hier gibt es keinen üblichen Pfad im Dateisystem, der hört in der Regel beim JAR-Archiv selbst auf.
Zum Nutzen der getResourceAsStream(String)-Methoden ist ein Class-Objekt nötig, das wir in unserem Fall über Klassenname.class besorgen. Das ist nötig, weil unser main(String[]) statisch ist. Andernfalls kann innerhalb von Objektmethoden auch getClass() eingesetzt werden, eine Methode, die jede Klasse aus der Basisklasse java.lang.Object erbt.
7.1.6Die Schnittstellen Closeable, AutoCloseable und Flushable
Zwei besondere Schnittstellen, Closeable und Flushable, schreiben Methoden vor, die alle Ressourcen implementieren, die geschlossen und/oder Daten aus einem internen Puffer herausschreiben sollen.
Closeable
Closeable wird von allen lesenden und schreibenden Datenstromklassen implementiert, die geschlossen werden können. Das sind alle Reader/Writer- und InputStream/OutputStream-Klassen und weitere Klassen wie Socket.
extends AutoClosable
void close() throws IOException
Schließt den Datenstrom. Einen geschlossenen Strom noch einmal zu schließen, hat keine Konsequenz.
Die Schnittstelle Closeable erweitert java.lang.AutoCloseable, sodass alles, was Closeable implementiert, damit vom Typ AutoCloseable ist und als Variable bei einem try mit Ressorcen verwendet werden kann.
void close() throws Exception
Schließt den Datenstrom. Einen geschlossenen Strom noch einmal zu schließen, hat keine Konsequenz.
Abbildung 7.1Das Klassendiagramm zeigt die Vererbungsbeziehung
zwischen Closeable und AutoCloseable.
[»]Hinweis
Jeder InputStream, OutputStream, Reader und Writer implementiert close() – und mit dem close() auch den Zwang, eine geprüfte IOException zu behandeln. Bei einem Eingabestrom ist die Exception nahezu wertlos und kann auch tatsächlich ignoriert werden. Bei einem Ausgabestrom ist die Exception schon deutlich wertvoller. Das liegt an der Aufgabe von close(), die nicht nur darin besteht, die Ressource zu schließen, sondern vorher noch gepufferte Daten zu schreiben. Somit ist ein close() oft ein indirektes write(…), und hier ist es sehr wohl wichtig zu wissen, ob alle Restdaten korrekt geschrieben wurden. Die Ausnahme sollte auf keinen Fall ignoriert werden, und der catch-Block darf nicht einfach leer bleiben; Logging ist hier das Mindeste.
Flushable
Flushable findet sich nur bei schreibenden Klassen und ist insbesondere bei den Klassen wichtig, die Daten puffern:
void flush() throws IOException
Schreibt gepufferte Daten in den Strom.
Die Basisklassen Writer und OutputStream implementieren diese Schnittstelle, aber auch Formatter tut dies.
