12.5 PrintStream und Konsolenausgaben 

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.

12.5.1 Die Klasse PrintStream 

Typisch für PrintStream – und später für PrintWriter – 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, sondern setzt intern 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 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. Die Konvertierung in Byte geschieht nach der Standard-Kodierung der Plattform.

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

PrintStream( OutputStream out ) Erzeugt einen neuen PrintStream, der die Ausgaben in out weiterleitet.

PrintStream( String fileName ) throws FileNotFoundException Schreibt die Ausgaben in die Datei.

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

PrintStream( OutputStream out, boolean autoFlush, String encoding ) throws UnsupportedEncodingException Erzeugt einen PrintStream, mit gewünschter Pufferleerung und Zeichenkodierung.

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.

PrintStream printf( String format, Object... args ) Formatierung mit Formatierungsstring.

PrintStream printf( Locale l, String format, Object... args ) Formatierung mit Formatierungsstring und Ländereinstellung.

protected void setError() Setzt den Fehlerstatus auf true.

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

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

Zusätzlich kommen 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 wird:

interface java.io.  Appendable  

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

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

Appendable append( CharSequence csq, int start, int end ) Hängt einen Teil der Zeichenfolge an diesen Appendable an und liefert ihn 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. Hinzu kommen die beiden Klassen StringBuffer und StringBuilder.

Kovariante 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. So verfährt auch PrintStream, und deswegen 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.

  System.out.  println( "\nGib mir eine Zeile Text: " );
byte[] buffer = new byte[ 255 ];
try
{
    System.in.  read( buffer, 0, 255 );
}
catch ( IOException e )

{
  System.out.println( e );
}
System.out.println( "\nDu hast mir gegeben:" );
System.out.println( new String(buffer) );

final class java.lang.  System  

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

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

static final 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.

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." );

Eine Möglichkeit besteht darin, das statische import zu nutzen. Doch auch mit einem 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!" );
  }
}

12.5.4 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 die Tatsache, 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();
}

Es 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 Byte 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 zur 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 in Javac anfangs 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 anhand von setOut0() vor Augen führen:

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, nicht sehr schö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 ohnehin 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 );

12.5.5 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 erwünschte Eigenschaften. Wir können jedoch bei speziellen Terminals Kontrollzeichen ausgeben, sodass 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 auf einem VT100-Terminal lauffähig. Andere Varianten müssen speziell angepasst werden.

Jcurzez

Die LGPL-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.