12.5 Daten filtern durch FilterInputStream und FilterOutputStream 

Die Daten, die durch irgendwelche Kanäle zum Benutzer kommen, können durch zwei spezielle Klassen gefiltert werden: FilterInputStream und FilterOutputStream. Eine Filter-Klasse überschreibt alle Methoden von InputStream und OutputStream und ersetzt diese durch neue Methoden mit erweiterter Funktionalität. Unterklassen von FilterInputStream und FilterOutputStream zeigt die folgende Tabelle.

Die Klasse LineNumberInputStream sollte nicht mehr verwendet werden, da sie veraltet ist. (Dafür gibt es aber LineNumberReader als Reader-Klasse.) Die besondere Unterklasse PrintStream vom FilterOutputStream wollen wir getrennt gehandeln.

Hier klicken, um das Bild zu Vergrößern

Am UML-Diagramm fällt besonders auf, dass jeder Filter selbst ein Stream ist und zum anderen einen Stream verwaltet. Damit nimmt er Daten entgegen und leitet sie gleich weiter. Das ist ein bekanntes Design-Pattern und nennt sich Dekorator.

12.5.1 Der besondere Filter PrintStream 

Schon in den ersten Programmen haben wir ein PrintStream-Objekt verwendet – doch vermutlich, ohne es zu wissen. Es steckte im out-Attribut der Klasse System. Es sind die vielen überladenen println()- und print()-Funktionen, die auf allen Datentypen operieren. So ist auch die Aufgabe definiert: Ausgabe unterschiedlicher Daten mittels einer überladenen Funktion. Im Gegensatz zum DataOutputStream erzeugt das PrintStream auch keine IOException. Intern setzt die Klasse jedoch ein Flag, welches durch die Methode checkError() nach außen kommt. Technisch gesehen ist ein PrintStream ein FilterOutputStream. So wie jeder Filter muss ein PrintStream-Objekt mit einem Ausgabeobjekt verbunden sein. Im Konstruktor kann zusätzlich noch ein Auto-Flush übergeben werden, das bestimmt, ob die Daten bei einem println() – oder beim Byte »\n« in der Zeichenkette – aus dem Puffer gespült werden. Alle Methoden sind synchronized, und die Ausgabemethoden passen die Zeichenketten an die jeweilige Kodierung an.

class java.io.  PrintStream  
extends FilterOutputStream
implements Appendable, Closeable

PrintStream( OutputStream out ) Erzeugt einen neuen PrintStream.

PrintStream( OutputStream out, boolean autoFlush ) Erzeugt einen neuen PrintStream, der automatisch beim Zeilenende den Puffer leert.

boolean checkError() Testet, ob intern eine IOException aufgetreten ist.

void close() Schließt den Stream. Methode aus Closeable.

void flush() Schreibt den Puffer.

void print( boolean|char|char[]|double|float|int|long|String ) Schreibt die primitiven Daten, String und Char-Feld.

void print( Object o ) Ruft o.toString() auf und gibt das Ergebnis aus, wenn o ungleich null ist. Sonst ist die Ausgabe null.

void println() Schließt die Zeile mit einem Zeilenendezeichen ab.

void println( boolean|char|char[]|double|float|int|long|String|Object ) Wie oben, schließt aber die Zeile mit einem Zeilenendezeichen ab.

protected void setError() Setzt den Fehlerstatus auf true.

void write( byte buf[], int off, int len ) Schreibt len Bytes des Felds ab off in den Datenstrom.

void write( int b ) Schreibt Byte b in den Datenstrom.

Zuzsätzlichen kommen noch zwei append()-Funktionen aus Appendable hinzu.

Hier klicken, um das Bild zu Vergrößern

12.5.2 Die Schnittstelle Appendable 

Neu seit Java 5 ist die Schnittstelle Appendable, die zwei Methoden vorschreibt und auch von PrintStream implementiert werden:

interface java.io.  Appendable  

Appendable append( char c ) Hängt das Zeichen c an das aktuelle Appendable an und liefert das aktuelle Objetk vom Typ Appendable zurück.

Appendable append( CharSequence csq ) Hängt die Zeichenfolge an diesen Appendable an und liefert ihn auch wieder zurück.

Die Schnittstelle wird neben PrintStream auch von CharBuffer und allen Writer-Klassen implementiert, das heißt unter anderem von BufferedWriter, CharArrayWriter, FileWriter, FilterWriter, OutputStreamWriter, StringWriter.

Kovarianten Rückgabe in PrintStream an Appendable

An PrintStream und an Appendable lässt sich gut die kovariante Rückgabe ablesen. Vor Java 5 mussten die Unterklassen beziehungsweise die implementierenden Klassen sich mit dem Rückgabetyp exakt an die Oberklasse oder Schnittstelle halten. Nun kann der Rückgabetyp auch ein Untertyp sein. Das macht auch PrintStream so und so heißt es in der Klasse nicht append() mit der Rückgabe Appendable, sondern mit der Rückgabe PrintStream, was ein Appendable ist.

public PrintStream append( char c )
{
  print(c);
  return this;
}

12.5.3 System.in und System.out 

Für die Standardeingabe- und Ausgabegeräte, die normalerweise Tastatur und Bildschirm sind, sind zwei besondere Stream-Klassen definiert, die beim Laden der Klasse automatisch erzeugt werden und von uns genutzt werden können. Dies ist zum einen das Objekt System.in für die Eingabe und zum anderen das Objekt System.out für die Ausgabe. System.in ist ein Exemplar der Klasse InputStream (genauer gesagt vom Typ BufferedInputStream) und System.out beziehungsweise System.err ein Exemplar von PrintStream.

Listing 12.11   KonsolenHinUndHer.java

public class KonsolenHinUndHer
{
  public static void main( String args[] )
  {
      System.out.  println( "\nGib mir eine Zeile Text: " );

    byte buffer[] = new byte[255];

    try
    {
        System.in.  read( buffer, 0, 255 );
    }
    catch ( Exception e )
    {
      System.out.println( e );
    }
    System.out.println( "\nDu hast mir gegeben: ");

    System.out.println( new String(buffer) );
  }
}

final class java.lang.  System  

InputStream in Dies ist der Standardeingabestrom. Er ist immer geöffnet und nimmt die Benutzereingaben normalerweise über die Tastatur entgegen.

PrintStream out Der Standardausgabestrom. Er ist immer geöffnet und normalerweise mit der Bildschirmausgabe verbunden.

PrintStream err Der Standard-Fehlerausgabestrom. Er wurde eingeführt, um die Fehlermeldungen von den Ausgabemeldungen zu unterscheiden. Auch wenn der Ausgabekanal umgeleitet wird, bleiben diese Meldungen erreichbar.

Ströme umlenken

Für Applikationen ist es nur möglich, über die oben genannten Methoden die Standardeingabe auf einen beliebigen InputStream und die Standardausgabe auf einen beliebigen PrintStream umzuleiten. Bei einem Applet bekommen wir eine Security-Exception, da keine Ausgaben unterdrückt werden dürfen. Zum Ändern dienen die Methoden setIn(), setOut() und setErr().

final class java.lang.  System  

void setOut( PrintStream out ) Der Standardausgabekanal wird umgesetzt.

void setErr( PrintStream err ) Der Fehlerkanal wird auf den PrintStream err gesetzt.

void setIn( InputStream in ) Der Eingabestrom kann umgesetzt werden, um beispielsweise aus einer Datei oder Netzwerkverbindung Daten zu beziehen, die an in anliegen sollen.

Sehr erstaunlich in der System-Klasse ist, dass die Attribute in, out und err final sind und daher eigentlich nicht geändert werden können. Die Implementierung sieht deshalb auch etwas ungewöhnlich aus:

public final static InputStream in  = nullInputStream();
public final static PrintStream out = nullPrintStream();
public final static PrintStream err = nullPrintStream();

Die Methode nullPrintStream() ist noch skurriler.

private static InputStream nullInputStream()
    throws NullPointerException {
  if (currentTimeMillis() > 0)
      return null;
  throw new NullPointerException();
}

Da bleibt natürlich die Frage, wieso die Sun-Entwickler nicht gleich den Wert auf null gesetzt haben. Denn nichts anderes macht ja die intelligente Funktion. Die Lösung liegt im final-Konstruktor und in einer Compiler-Optimierung. Da finale Variablen später (eigentlich) nicht mehr verändert werden dürfen, kann der Compiler überall dort, wo in, out oder err vorkommt, eine null einsetzen und nicht mehr auf die Variablen zurückgreifen. Dies muss aber verboten werden, da diese drei Attribute später mit sinnvollen Referenzen belegt werden. Genauer gesagt ist dafür die Methode initializeSystemClass() zuständig. Ursprünglich kommen die Ströme aus dem FileDescriptor.

Für err und out werden dann hübsche BufferedOutputStream mit 128 Bytes Puffer angelegt, die sofort durchschreiben. in ist ein einfacher BufferedInputStream mit der Standardpuffergröße. Damit setIn(), setOut() und setErr() dann auf die final-Variable schreiben dürfen, müssen selbstverständlich native Methoden her, die setIn0(in), setOut0(out) und setErr0(err) heißen. Die Parameter der Funktionen sind die Argumente der öffentlichen set[Out|Err|In]()-Methoden. In initializeSystemClass() werden dann auch auf den gepufferten Strömen diese nativen Methoden angewendet.

Die Bastelei mit der nullPrintStream()-Methode ist nicht nötig, wenn der Java-Standard 1.1 vorliegt. Denn dort hat sich eine Kleinigkeit getan, die erst zu der umständlichen Lösung führte. Warum musste denn der Compiler die final-Variablen auch vorbelegen? Die Antwort ist, dass der 1.0-konforme Compiler direkt die final-Variablen initialisieren musste. Erst seit 1.1 kann an einer anderen Stelle genau einmal auf final-Variablen schreibend zugegriffen werden. Wir haben das schon an anderer Stelle beschrieben und die fehlerhafte Jikes-Implementierung aufgeführt, die auch zu Anfang in Javac zu Problemen bei der Doppelbelegung führte. Legen wir einen Java-1.1-Compiler zugrunde, was heute selbstverständlich ist, lässt sich die nullPrintStream() vermeiden. Wir können das an der Kaffe-Implementierung überprüfen, denn dort findet sich einfach:

final public static InputStream in;
final public static PrintStream out;
final public static PrintStream err;

Jetzt wird an einer definierten Stelle die Ein- beziehungsweise Ausgabe initialisiert.

in = new BufferedInputStream(
   new FileInputStream(FileDescriptor.in), 128);
out = new PrintStream( new BufferedOutputStream(
   new FileOutputStream(FileDescriptor.out), 128), true);
err = new PrintStream(new BufferedOutputStream(
   new FileOutputStream(FileDescriptor.err), 128), true);

Im Unterschied zur Sun-Implementierung muss hier nicht schon ein Aufruf der nativen Methoden verwendet werden, obwohl dies spätestens bei den setXXX()-Methoden nötig wird. Die Einfachheit einer solchen nativen Routine wollen wir uns zum Schluss einmal an setOut0() ansehen:

void Java_java_lang_System_setOut0
(JNIEnv *env, jclass system, jobject stream)
{
  jfieldID out = (*env)->GetStaticFieldID(
                   env, system,
                   "out", "Ljava/io/PrintStream;");
  assert(out);
  (*env)->SetStaticObjectField(env, system, out, stream);
}

Dies zeigt noch einmal sehr deutlich, dass final durch native Methoden außer Kraft gesetzt werden kann. Diese Lösung ist aber, wie wir schon festgestellt haben, sehr unschön. Damit aber die einfache Verwendung von out, err und in als Attribut möglich ist, bleibt außer dieser Konstruktion nicht viel übrig. Andernfalls hätte eine Methode Eingang finden müssen, aber

System.out().println( "Hui Buh" );

macht sich nicht so schön. Ließen sich in Java Variablen mit einem speziellen Modifizierer versehen, der nur den Lesezugriff von außen gewährt und nicht automatisch einen Schreibzugriff, so wäre das auch eine Lösung. Doch so etwas gibt es in Java nicht. Softwaredesigner würden sowieso Methoden nehmen, da sie Variablenzugriffe meist meiden.

Ausgabe in ein Fenster

Bei genauerer Betrachtung der Standardausgabe- und Eingabemethoden ist festzustellen, dass das Konzept nicht besonders plattformunabhängig ist. Wenn wir einen Macintosh als Plattform betrachten, dann lässt sich dort keine Konsole ausmachen. Bei GUI-Anwendungen spricht demnach einiges dafür, auf die Konsolenausgabe zu verzichten und die Ausgabe in ein Fenster zu setzen. Ich möchte daher an dieser Stelle etwas vorgreifen und ein Programmstück vorstellen, mit dem sich die Standardausgabeströme in einem Fenster darstellen lassen. Dann genügt Folgendes, unter der Annahme, dass die Variable ta ein TextArea-Objekt referenziert:

PrintStream p = new PrintStream(
  new OutputStream() {
    public void write( int b ) {
      ta.append( (char)b );
    }
  }
);
  System.setErr  ( p );
  System.setOut  ( p );

Den Bildschirm löschen und Textausgaben optisch aufwerten

Die Java-Umgebung setzt keine spezielle grafische Architektur voraus und kein spezielles Terminal. Als unabhängige Sprache gibt es daher außer der Textausgabe bisher keine Möglichkeit, die Farben für die Textzeichen zu ändern, den Cursor zu setzen oder den Bildschirm zu löschen. Bei Programmen mit Textausgabe sind dies aber gewünschte Eigenschaften. Wir können jedoch bei speziellen Terminals Kontrollzeichen ausgeben, so dass die Konsole Attribute speichert und Text somit formatiert ausgegeben werden kann. Bei einem VT100-Terminal existieren unterschiedliche Kontrollsequenzen, und über eine einfache Ausgabe System.out.println() lässt sich der Bildschirm löschen.

System.out.println( "\u001b[H\u001b[2J" );

Leider ist diese Lösung nur lauffähig auf einem VT100-Terminal. Andere Varianten müssen speziell angepasst werden.

Jcurzez

Die Bibliothek Jcurzez ist die Java-Version der Curses-Bibliothek, die Ausgaben auf einem Terminal steuert. Mit Jcurzez lassen sich Zeichenattribute auf der Konsole ändern, lässt den Cursor wandern und lassen sich einfache ASCII-Fenster erstellen. Die Bibliothek ist unter http://www.nongnu.org/jcurzez/ zu bekommen.

Schreibarbeit sparen

Natürlich ist es Schreibarbeit, immer die Angabe System.out.bla machen zu müssen, so wie in

System.out.println( "Das Programm gibt die Ausgabe: " );
System.out.println( 1.234 );
System.out.println( "Die drei Fragezeichen sind toll." );

Durch einen zusätzlichen Verweis können wir uns Arbeit sparen. Das Ganze funktioniert, da System.out ein Objekt vom Typ PrintStream ist.

Listing 12.12   SchnellerPrintStream.java

import java.io.*;

public class SchnellerPrintStream
{
  private static final   PrintStream o = System.out  ;

  public static void main( String args[] )
  {
      o.  println( "Neu!" );
      o.  println( "Jetzt noch weniger zu schreiben." );
      o.  println( "Hilft auch Gelenken wieder auf die Sprünge!" );
  }
}

In der Klasse OutputStream taucht die Funktion println() nicht auf. Für Systemausgaben wäre OutputStream auch viel zu unflexibel, daher nutzt die Klasse auch PrintStream-Objekte ab. Für eigene Projekte sollte die Klasse nicht mehr verwendet werden und wenn doch, dann nur noch für Debug-Code mittels System.out und aus Kompatibilitätsgründen. Wir stützen uns daher auf die Klasse PrintWriter, die die abstrakte Klasse Writer erweitert. Das Attribut System.out bleibt weiterhin vom Typ PrintStream. Die Deklaration PrintWriter o = System.out ist also falsch (das ist zum Beispiel solch ein Kompatibilitätsgrund).