8.7    Automatisches Ressourcen-Management (try mit Ressourcen) 

Java hat eine automatische Speicherbereinigung, die nicht mehr referenzierte Objekte erkennt und ihren Speicher automatisch freigibt. Nun bezieht sich der Garbage-Collector aber ausschließlich auf Speicher, doch es gibt viele weitere Ressourcen:

• Dateisystemressourcen von Dateien

• Netzwerkressourcen wie Socket-Verbindungen

• Datenbankverbindungen

• nativ gebundene Ressourcen des Grafiksubsystems

• Synchronisationsobjekte

Auch hier gilt es, nach getaner Arbeit aufzuräumen und Ressourcen freizugeben, etwa Dateien und Datenbankverbindungen zu schließen.

Mit dem try-catch-finally-Konstrukt haben wir gesehen, wie Ressourcen freizugeben sind. Doch es lässt sich auch ablesen, dass relativ viel Quellcode geschrieben werden muss und dass try-catch-finally drei Unfeinheiten hat:

1. Soll eine Variable in finally zugänglich sein, muss sie außerhalb des try-Blocks deklariert werden, was ihr eine längere Sichtbarkeit als nötig gibt.

2. Das Schließen der Ressourcen bringt oft ein zusätzliches try-catch mit sich.

3. Eine im finally ausgelöste Ausnahme (etwa beim close()) überdeckt die im try-Block ausgelöste Ausnahme.

 

8.7.1    try mit Ressourcen 

Um das Schließen von Ressourcen zu vereinfachen, gibt es eine besondere Form der try-Anweisung, die try mit Ressourcen heißt. Mit diesem Sprachkonstrukt lassen sich Ressourcentypen automatisch schließen, die die Schnittstelle java.lang.AutoCloseable implementieren. Ein-/Ausgabeklassen wie Scanner, InputStream und Writer implementieren diese Schnittstelle und können direkt verwendet werden. Weil try mit Ressourcen dem Automatic Resource Management dient, heißt der spezielle try-Block auch ARM-Block.

Gehen wir in die Praxis: Aus einer Datei soll mit einem Scanner die erste Zeile gelesen und ausgegeben werden. Nach dem Lesen soll der Scanner geschlossen werden. Die linke Seite von Tabelle 8.3 nutzt die spezielle Syntax, die rechte Seite ist im Prinzip die Übersetzung, allerdings noch etwas vereinfacht, wie wir später genauer sehen werden.

InputStream in = ClassLoader.getSystemResourceAsStream( "EastOfJava.txt" );

try ( Scanner res = new Scanner( in ) ) {

{ 

  Scanner res = new Scanner( in );

  try {

System.out.println( res.nextLine() );

}

}

 finally {

  res.close();

 }

}

Tabelle 8.3    Vereinfache Umsetzung von »try mit Ressourcen«

Bisher haben wir nach dem Schlüsselwort try direkt einen Block gesetzt, doch try mit Ressourcen nutzt eine eigene erweiterte Syntax: Nach dem try folgt statt des direkten {}-Blocks eine Ressourcenspezifikation in runden Klammern und dann erst der {}-Block, also try (…) {…} statt try {…}.

Die Ressourcenspezifikation besteht aus einem Satz runder Klammern und einer Liste von Ressourcen. Die Ressourcen sind finale Variablen vom Typ AutoCloseable, und genau diese werden später automatisch geschlossen. Die Variablen können mit einem Gleichheitszeichen direkt mit einem Ausdruck initialisiert werden, etwa mit einem Konstruktor- oder Methodenaufruf. Vor Java 9 war die Initialisierung zwingend. Der Einsatz von var ist erlaubt.

Die in dem try deklarierte lokale AutoCloseable-Variable ist nur in dem Block gültig und wird automatisch freigegeben, gleichgültig, ob der ARM-Block korrekt durchlaufen wurde oder ob es bei der Abarbeitung zu einer Ausnahme kam. Der Compiler fügt alle nötigen Prüfungen ein.

 

8.7.2    Die Schnittstelle AutoCloseable 

Das try mit Ressourcen schließt Ressourcen vom Typ AutoCloseable. Daher wird es Zeit, sich diese Schnittstelle etwas genauer anzuschauen:

Listing 8.26    java/lang/AutoCloseable.java

package java.lang;



public interface AutoCloseable {

  void close() throws Exception;

}

Anders als das übliche close() ist die Ausnahme deutlich allgemeiner mit Exception angegeben; die Ein-/Ausgabe-Klassen lösen beim Misslingen immer eine IOException aus, aber jede Klasse hat eigene Ausnahmetypen:

Tabelle 8.4    Einige Typen, die »AutoCloseable« implementieren bzw. erweitern

Eine Unterklasse darf die Ausnahme bei throws weglassen. Das machen Klassen wie der Scanner, der bei den Methoden keine Ausnahme weiterleitet, sondern Ausnahmen intern abfängt und die letzte Ausnahme später über die Methode ioException() zugänglich macht.

AutoCloseable und Closeable

Auf den ersten Blick einleuchtend wäre es, die schon existierende Schnittstelle Closeable als Typ zu nutzen. Doch das hätte Nachteile: Die close()-Methode ist mit einem throws IOException deklariert, was bei einer allgemeinen automatischen Ressourcenfreigabe unpassend ist, wenn etwa ein Grafikobjekt bei der Freigabe eine IOException auslöst. Vielmehr ist der Weg andersherum: Closeable erweitert AutoCloseable, denn das Schließen von Ein-/Ausgabe-Ressourcen ist eine besondere Art, allgemeine Ressourcen zu schließen.

package java.io;



import java.io.IOException;



public interface Closeable extends AutoCloseable {

  void close() throws IOException;

}

Wer ist AutoCloseable?

Da alle Klassen, die Closeable implementieren, auch automatisch vom Typ AutoCloseable sind, kommen schon einige Typen zusammen. Im Wesentlichen sind es aber Klassen aus dem java.io-Paket, wie Channel-, Reader-, Writer-Implementierungen, FileLock, XMLDecoder und noch ein paar Exoten wie URLClassLoader, ImageOutputStream. Auch Typen aus dem java.sql-Paket gehören zu den Nutznießern. Klassen aus dem Bereich Threading, wo etwa ein Lock wieder freigegeben werden könnte, oder Grafikanwendungen, bei denen der Grafikkontext wieder freigegeben werden muss, gehören nicht dazu.

ReentrantLock lock = new ReentrantLock();

try ( AutoCloseable unlock = lock::unlock ) { // oder () -> {lock.unlock();}

 lock.lock();

}

System.out.println( lock.isLocked() );  // false

 

8.7.3    Mehrere Ressourcen nutzen 

Unsere beiden Beispiele zeigen die Nutzung eines Ressourcentyps. Es sind aber auch mehrere Typen möglich, die ein Semikolon trennt:

try ( InputStream  in  = Files.newInputStream( srcPath );

      OutputStream out = Files.newOutputStream( destPath ) ) {

  ...

}

Weiterhin ist es erlaubt, dass die nachfolgende Ressource auf die vorherige Ressource verweist, sodass geschachtelte Ströme möglich sind:

try ( InputStream fis = Files.newInputStream( srcPath );

      InputStream bis = new BufferedInputStream( fis ) ) {

  ...

}

Dieses Modell findet oft bei Dekoratoren Anwendung.

try ( InputStream in1 = ...; InputStream in2 = ... )

try ( InputStream in1 = ..., in2 = ... )    //  Compilerfehler

int[] array = { 1, 2, };

//                  ^ Komma optional

try ( InputStream in = Files.newInputStream( path ); ) { ... }

//                                                 ^ Semikolon optional

try ( InputStream  in  = Files.newInputStream( src );

      OutputStream out = Files.newOutputStream( dest ); ) { ... }

//                                                    ^ Semikolon optional

Reihenfolge beim Schließen

Die Ressourcen werden in der umgekehrten Reihenfolge geschlossen, wie sie geöffnet wurden.

try ( InputStream  in  = Files.newInputStream( srcPath );

      OutputStream out = Files.newOutputStream( destPath ) ) {

  ...

}

Kommt es beim Anlegen in der Kette zu einer Ausnahme, wird nur die Ressource geschlossen, die geöffnet wurde. Wenn es also in dem gerade genannten Beispiel bei der ersten Initialisierung von in knallt, wird die Belegung von out erst gar nicht begonnen und daher auch nicht geschlossen. (Intern setzt der Compiler das als geschachtelte try-catch-finally-Blöcke um.)

 

8.7.4    try mit Ressourcen auf null-Ressourcen 

Dass immer zum Abschluss eines try-mit-Ressourcen-Blocks ein close() aufgerufen wird, ist nicht ganz korrekt. Es gibt nur dann einen Schließversuch, wenn die Ressource ungleich null ist.

try ( Scanner scanner1 = null; Scanner scanner2 = null ) {

  System.out.println( "Ok" );

}

Bei Konstruktoren ist ein Objekt ja immer gegeben, aber es gibt auch Fabrikaufrufe, bei denen vielleicht null herauskommen kann. Für diese Fälle ist es ganz praktisch, dass try mit Ressourcen dann nichts macht, um eine NullPointerException beim close() zu vermeiden.

 

8.7.5    Ausnahmen vom close() 

Unser Scanner-Programm aus dem ersten Beispiel hat eine Besonderheit, denn keine der Methoden löst eine geprüfte Ausnahme aus – weder getSystemResourceAsStream(…), new Scanner(InputStream), nextLine() noch das close(), das try mit Ressourcen automatisch aufruft. Anders ist es, wenn die Ressource ein klassischer Datenstrom (InputStream/OutputStream/Reader/Writer) ist, denn dort deklariert die close()-Methode eine IOException. Die muss daher auch behandelt werden, wie es das folgende Beispiel zeigt:

Listing 8.27    TryWithResourcesReadsLine, readFirstLine()

static String readFirstLine( String file ) {

  try ( BufferedReader br = Files.newBufferedReader(

          Paths.get( file ), StandardCharsets.ISO_8859_1 ) ) {

    return br.readLine();

  }

  catch ( IOException e ) { e.printStackTrace(); return null; }

}

Wenn try mit Ressourcen verwendet wird, bleibt die deklarierte Ausnahme bei close() bestehen; es zaubert die in der Regel ausgelöste IOException nicht weg, und entweder muss ein fangendes catch her oder die Ausnahme muss weitergeleitet werden. Daraus ergibt sich ein interessanter Nebeneffekt: Hat ein Aufruf von einem IOException-auslösenden close() im Code gefehlt und wird Programmcode in der try-mit-Ressourcen-Syntax umgeschrieben, so führt der vom Compiler automatisch eingesetzte close()-Aufruf zu einem Compilerfehler, wenn die geprüfte IOException nicht behandelt wird.

void no() {

  try ( Reader r = new BufferedReader(null) ) { }    //  Compilerfehler

}

 

8.7.6    Unterdrückte Ausnahmen * 

Aufmerksame Leser haben bestimmt schon ein Detail wahrgenommen: In Tabelle 8.3 steht »vereinfachte ausgeschriebene Implementierung«, was vermuten lässt, dass es ganz so einfach doch nicht ist. Das stimmt, denn es können zwei Ausnahmen auftauchen, die einiges an Sonderbehandlung benötigen:

• Ausnahme im try-Block, an sich unproblematisch

• Ausnahme beim close(), auch an sich unproblematisch. Aber es gibt mehrere close()-Aufrufe, wenn nicht nur eine Ressource verwendet wurde: Ungünstig.

• Die Steigerung: Ausnahme im try-Block und dann auch noch Ausnahme(n) beim close(). Das ist ein echtes Problem!

Eine Ausnahme allein ist kein Problem, aber zwei Ausnahmen auf einmal bilden ein großes Problem, da ein Programmblock nur genau eine Ausnahme melden kann und nicht eine Sequenz von Ausnahmen. Daher sind verschiedene Fragen zu klären, falls der try-Block und close() beide eine Ausnahme auslösen:

• Welche Ausnahme ist wichtiger? Die Ausnahme im try-Block oder die vom close()?

• Wenn es zu zwei Ausnahmen kommt: Soll die von close() vielleicht immer verdeckt werden und immer nur die vom try-Block zum Anwender kommen?

• Wenn beide Ausnahmen gleich wichtig sind, wie sollen sie gemeldet werden?

Wie haben sich die Java-Ingenieure entschieden? Eine Ausnahme bei close() darf bei einem gleichzeitigen Auftreten einer Exception im try-Block auf keinen Fall verschwinden.[ 190 ](In einem frühen Prototyp war dies tatsächlich der Fall – die Ausnahme wurde komplett geschluckt. ) Wie also beide Ausnahmen melden? Hier gibt es einen Trick: Da die Ausnahme im try-Block wichtiger ist, ist sie die »Hauptausnahme«, und die close()-Ausnahme kommt Huckepack als Extra-Information mit obendrauf.

Dieses Verhalten soll das nächste Beispiel zeigen. Um die Ausnahmen besser steuern zu können, soll eine eigene AutoCloseable-Implementierung eine Ausnahme in close() auslösen.

Listing 8.28    src/main/java/com/tutego/insel/exception/NotCloseable.java, Ausschnitt

public class NotCloseable implements AutoCloseable {

  @Override public void close() {

    throw new UnsupportedOperationException( "close() mag ich nicht" ); // 

  }

}

Die Klasse NotCloseable wollen wir als Ressource nutzen:

Listing 8.29    src/main/java/com/tutego/insel/exception/SuppressedClosed.java, Ausschnitt

public class SuppressedClosed {

  public static void main( String[] args ) {

    try ( NotCloseable res = new NotCloseable() ) {

      throw new NullPointerException();            // 

    }

  }

}

NotCloseable löst im close() eine Ausnahme aus, die beim try-mit-Ressourcen ankommt. Ohne catch bricht die JVM den Thread ab und das Resultat auf der Konsole ist:

Exception in thread "main" java.lang.NullPointerException

 at com.tutego.insel.exception.SuppressedClosed.main(SuppressedClosed.java:6)

 Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht

  at com.tutego.insel.exception.NotCloseable.close(NotCloseable.java:4)

  at com.tutego.insel.exception.SuppressedClosed.main(SuppressedClosed.java:7)

Die Hauptausnahme ist die NullPointerException. Die interessante Zeile beginnt mit Suppressed:, denn dort ist die close()-Ausnahme referenziert. An den Aufrufer kommt die spannende Ausnahme des misslungenen try-Blocks aber nicht direkt von close(), sondern verpackt in der Hauptausnahme und muss extra erfragt werden.

Zum Vergleich: Kommentieren wir throw new NullPointerException() aus, gibt es nur noch die close()-Ausnahme, und es folgt auf der Konsole:

Exception in thread "main" java.lang.UnsupportedOperationException: close() mag ich nicht

 at com.tutego.insel.exception.NotCloseable.close(NotCloseable.java:4)

 at com.tutego.insel.exception.SuppressedClosed.main(SuppressedClosed.java:7)

Die Ausnahme ist also nicht irgendwo anders untergebracht, sondern die »Hauptausnahme«. Eine Steigerung ist, dass es mehr als eine Ausnahme beim Schließen geben kann. Simulieren wir auch dies wieder an einem Beispiel, indem wir unser Beispiel um eine Zeile ergänzen:

Listing 8.30    src/main/java/com/tutego/insel/exception/SuppressedClosed2.java, Ausschnitt

try ( NotCloseable res1 = new NotCloseable();

      NotCloseable res2 = new NotCloseable() ) {

    throw new NullPointerException();

}

Aufgerufen führt dies zu:

Exception in thread "main" java.lang.NullPointerException

 at com.tutego.insel.exception.SuppressedClosed2.main(SuppressedClosed2.java:7)

 Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht

  at com.tutego.insel.exception.NotCloseable.close(NotCloseable.java:4)

  at com.tutego.insel.exception.SuppressedClosed2.main(SuppressedClosed2.java:8)

 Suppressed: java.lang.UnsupportedOperationException: close() mag ich nicht

  at com.tutego.insel.exception.NotCloseable.close(NotCloseable.java:4)

  at com.tutego.insel.exception.SuppressedClosed2.main(SuppressedClosed2.java:8)

Jede unterdrückte close()-Ausnahme taucht auf.

Spezielle Methoden in Throwable *

Damit eine normale Exception die unterdrückten close()-Ausnahmen Huckepack nehmen kann, gibt es in der Basisklasse Throwable zwei besondere Methoden:

final class java.lang.Throwable

• final Throwable[] getSuppressed()
  
  Liefert alle unterdrückten Ausnahmen. Die printStackTrace(…)-Methode zeigt alle unterdrückten Ausnahmen und greift auf getSuppressed() zurück. Für Anwender wird es selten Anwendungsfälle für diese Methode geben.

• final void addSuppressed(Throwable exception)
  
  Fügt eine neue unterdrückte Ausnahme hinzu. In der Regel ruft der finally-Block vom try mit Ressourcen die Methode auf, doch wir können auch selbst die Methode nutzen, wenn wir mehr als eine Ausnahme melden wollen. Die Java-Bibliothek selbst nutzt das bisher nur an sehr wenigen Stellen.

Neben den beiden Methoden gibt es einen protected-Konstruktor, der bestimmt, ob es überhaupt unterdrückte Ausnahmen geben soll oder ob sie nicht vielleicht komplett geschluckt werden. Wenn, dann zeigt auch printStackTrace(…) sie nicht mehr an.