Die Version 7 von Java wird eine Reihe von kleineren Sprachergänzungen bringen, die unter dem Namen "Project Coin" entwickelt wurden.  In diesem Beitrag stellen wir einen Teil dieser neuen Sprachmittel aus dem Project Coin vor, nämlich verbesserte Notationen für numerische Literale, Strings in switch-Anweisungen, Verbesserungen beim Exception Handling und das Automatic Resource Management.  Die übrigen Verbesserungen im Zusammenhang mit Generics werden wir im nächsten Artikel besprechen.

"Project Coin"  ist eine Sammlung kleinerer Spracherweiterungen.  Die Ideen für diese Ergänzungen stammen aus der Java Community selbst.  Sun Microsystems hatte die Community aufgefordert, entsprechende Vorschläge zu machen, und hatte aus der Fülle der Ideen eine Handvoll aufgegriffen.  Die Idee dabei war es, die Sprache um Mittel zu erweitern, die nützlich und "klein" sind.

Folgende neue Sprachmittel werden mit Java 7 freigegeben:

• Verbesserte Schreibweisen für numerische Literale
• Strings in switch-Anweisungen
• Verbessertes Exception Handling
• Automatic Resource Management
• Vereinfachungen beim Aufruf von Methoden mit variabler Argumentenliste
• Verbesserte Type Inference für Konstruktoren generischer Typen ( diamond operator)

Verbesserte Schreibweise für numerische Literale

Binary Literals

Hier ist ein Beispiel für die neue Binär-Darstellung:

    int decimal = 43;
    int hex     = 0x2B;
    int octal   = 053;
    int binary  = 0b101011;

Underscores in Numbers

Hier ein paar Beispiele:

long phoneNumber      = +49_721_6291_88L;
long creditCardNumber = 1234_5678_9012_3456L;
long hexWords         = 0xFFEC_DE5E;

Strings in switch-Anweisungen

     private static final String IDLE = "idle";

    public static void newStringSwitch(String state) {
        final String terminal = "terminated";

        if (state== null)
            System.out.println("No state");
        switch (state) {
        case "busy":   // fall through works as before
        case terminal: // local final variables are ok
        case IDLE: {   // constants are ok
            System.out.println("Matched state");
            break; }
        default: {
            System.out.println("Unknown state");
            break; }
        }
    }

Im switch wird über eine String-Variable verzweigt und die case -Labels dürfen String-Literale oder final String-Variablen sein; non- final String-Variablen sind als case -Labels nicht erlaubt.

Der Effizienzzuwachs rührt daher, dass man mit heutigen Sprachmitteln eine if - else -Kaskade mit equals() -Vergleichen für alle Strings hinschreiben müsste.  Eine solche Kaskade kann vom Compiler schlecht optimiert werden.  Aus einem switch über Strings kann der Compiler hingegen einen switch über die Hashcodes der Strings machen, was dann nur noch einen einzigen equals() -Aufruf statt einer Sequenz von Methodenaufrufen erfordert.

Mit herkömmlichen Mitteln wäre die Verzweigung im obigen Beispiel nur mit einer if - else -Kaskade möglich gewesen, in der der variable String state sukzessive mit allen konstanten Strings verglichen wird, bis eine Übereinstimmung gefunden wird.  Das hätte dann etwa so ausgesehen:

    public static void classicStringSwitch(String state) {
        System.out.println("OLD ...");
        final String terminal = "terminated";
        if (state== null)
            System.out.println("No state");
        else if (state.equals("busy") || state.equals(terminal) || state.equals(IDLE))
            System.out.println("Matched state");
        else
            System.out.println("Unknown state");// default
    }

    public static void newStringSwitch(String state) {
        if(s == null)
            System.out.println("No state");
        String s1 = state;
        byte byte0 = -1;
        switch(s1.hashCode())
        {
        case 3035641:
            if(s1.equals("busy"))
                byte0 = 0;
            break;

        case -1308815837:
            if(s1.equals("terminated"))
                byte0 = 1;
            break;

        case 3227604:
            if(s1.equals("idle"))
                byte0 = 2;
            break;
        }
        switch(byte0)
        {
        case 0:
        case 1:
        case 2:
            System.out.println("Matched state");
            break;

        default:
            System.out.println("Unknown state");
            break;
        }
    }

Verbessertes Exception Handling

Flexibilisierung beim Rethrow von Exceptions

    public void someMethod throws SomeSpecificException {
        …
        try {
            doWork(file);  // might throw SomeSpecificException
        } catch (Throwable ex) {
            // some cleanup activity
            throw ex;    // error
        }
        …
    }
_______________________________________________________________________
unreported exception Throwable; must be caught or declared to be thrown
            throw ex;
            ^

    public void someMethod throws SomeSpecificException {
        …
        try {
            doWork(file);  // might throw SomeSpecificException
        } catch (Throwable ex) {
            // some cleanup activity
            throw ex;     // fine
        }
        …
    }

Allerdings darf man an die Referenzvariable ex im catch -Block nichts zuweisen, wenn man einen Rethrow machen will.  Sobald im catch -Block an die Referenzvariable ex zugewiesen wird, weigert sich der Compiler, einen Rethrow zu akzeptieren.  Der Compiler erkennt nämlich daran, dass der Referenzvariablen im catch -Block  nichts Neues zugewiesen wurde, dass es sich um einen Rethrow der Original-Exception handelt und dass nicht etwa eine andere Exception geworfen wird.  Wenn man eine Zuweisung Referenzvariable im catch -Block macht, dann ist es eben kein Rethrow mehr.

In diesem Fall behandelt der Compiler die Exception dann so, wie früher in Java 6 schon:  er beschwert sich darüber, dass die Methode eine Exception vom Typ Throwable wirft, diesen Exception-Typ aber nicht in ihrer throws -Klausel deklariert hat und dann muss man die throws -Klausel der Methode ändern und throwsThrowable deklararieren.

Man sich sollte deshalb merken, dass die Referenzvariable ex im catch -Block "effectively final" sein muss, wenn man einen Rethrow machen will.  Das heißt, man muss die Variable zwar nicht ausdrücklich als final deklarieren, aber man sollte sie dennoch wie eine final -Variable behandeln.
 

Multi-Catch

    public void someMethod throws IOException,InterruptedException {
        …
        try {
            doWork(file);
        } catch (IOException ex) {
            logger.log(ex);
            throw ex;
        }catch (InterruptedException ex) {
            logger.log(ex);
            throw ex;
        }
        …
    }

    public void someMethod throws IOException,InterruptedException {
        …
        try {
            doWork(file);
        } catch ( IOException | InterruptedException ex) {
            logger.log(ex);
            throw ex;
        }
        …
    }

    public void someMethod throws Exception {
        …
        try {
            doWork(file);
        } catch ( Exception ex) {
            logger.log(ex);
           throw ex;
        }
        …
    }

Es gibt eine Randbedingung bei der Verwendung des neuen Multicatch-Features: die Referenzvariable ex im catch -Block ist "effectively final".  Das heißt, man muss die Variable nicht ausdrücklich als final IOException | InterruptedException ex deklarieren, aber sie wird dennoch wie eine final -Variable behandelt und man darf an diese Variable nichts zuweisen.  Wenn man es trotzdem tut, bekommt man eine Fehlermeldung vom Compiler, die besagt, man dürfe an den Multicatch-Parameter nichts zuweisen.

Automatic Resource Management

Damit wird ein Problem gelöst, das schon so alt ist wie Java selbst.  In Java gibt es zwar Konstruktoren, in denen ein Objekt zu Beginn seiner Lebenszeit Ressourcen beschaffen kann, aber es gibt kein gutes Instrument, mit dem das Objekt seine Ressourcen beim Ableben automatisch loswerden könnte.  Die Finalizer haben sich für diesen Zweck als wenig hilfreich erwiesen und so muss sich der Benutzer des Objekts meist selbst darum kümmern, dass die Ressourcen des Objekts freigegeben werden.

Am Beispiel eines Input-Streams sieht es so aus:

String readFirstLineFromFile(String path) throws IOException {
  BufferedReader br = new BufferedReader(new FileReader(path));
  try     { return br.readLine(); }
  finally { br. close (); }
}

In dieser Situation soll das Automatic Resource Management helfen.  Die Idee besteht darin, dass Klassen mit dynamischen Ressourcen, wie z.B. ein BufferedReader , ein spezielles Interface AutoCloseable implementieren können (und im Fall von JDK Klassen auch tun):

public interface AutoCloseable {
  void close() throws Exception;
}

Dazu gibt es eine neue Form des try -Blocks, ein sogenanntes "try-with-resources", bei dessen Verlassen automatisch die close() -Methoden aller spezifizierten Resource-Typen aufgerufen werden.  Das sähe zum Beispiel so aus:

String readFirstLineFromFile(String path) throws IOException {
    try ( BufferedReader br = new BufferedReader(new FileReader(path)) ) {
      return br.readLine();
    }
}

String readFirstLineFromFile(String path) throws IOException {
    try ( FileReader    fin = new FileReader(path);
         BufferedReader br = new BufferedReader(fin) ) {
      return br.readLine();
    }
}

Suppressed Exceptions

Ohne try-with-resources sähe es so aus:

void method() throws Exception {
  Resource r = new Resource();
  try { ... does something useful that may raise an exception ...
        throw new Exception("from try block");
  } catch (Exception e) {
        ... does cleanup and re-throws initial exception ...
        throw e;
  } finally {
        r.close();
  }
}

Mit try-with-resources sähe es so aus:

void method() throws Exception {
  try (Resource r = new Resource()) {
     ... does something useful that may raise an exception ...
     throw new Exception("from try block");
  } catch (Exception e) {
     ... does cleanup and re-throws initial exception ...
     throw e;
  }
}

Nun stellt sich die Frage: was passiert eigentlich, wenn ein try-with-resources-Konstrukt eine explizite finally -Klausel hat und darin auch eine Exception geworfen wird?  Hier ist ein Beispiel:

void method() throws Exception {
  try (Resource r = new Resource()) {
     ... does something useful that may raise an exception ...
     throw new Exception("from try block");
  } finally {
     ... does something useful that may raise an exception ...
     throw new Exception("from finally block");
  }
}

Da die close() -Methoden aller Ressourcen vor den Anweisungen im finally -Block aufgerufen werden, sind wir wieder in der Situation, in der wir ohne das neue try-with-resources-Konstrukt waren: es wird nur die allerletzte Exception aus dem finally -Block geworfen; die Exception aus dem try -Block mit der eingepackten Exception aus der close() -Methode geht verloren.

Wie ist die Situation, wenn es noch komplizierter wird und es im try-with-resources-Konstrukt sowohl eine catch - als auch eine finally -Klausel gibt?  Im Wesentlichen ist es so wie oben beschrieben:  nach Verlassen des try -Block werden die close() -Methoden der Ressourcen gerufen, danach geht es im catch - und anschließend im finally -Block weiter.

void method() throws Exception {
  try (Resource r = new Resource()) {
     ... does something useful that may raise an exception ...
     throw new Exception("from try block");
  }
                        <= Hier werden die close()-Methoden gerufen.
  catch(Exception e) {
     ... does cleanup and re-throws initial exception ...
     throw e;
  }
  finally {
     ... final work ...
  }
}

Sinnvoll ist also im catch -Block nur

• der Rethrow der initialen Exception, welche dann automatisch die Exception von einer close() -Methode als unterdrückte Exception mitbringt, oder
• das Behandeln der initialen Exception; nach der Behandlung wird dann keine Exception mehr propagiert, oder
• wenn man eine andere als die initiale Exception werfen will, dann sollte man explizit die vorangegangene Exception eingepackt mitliefern.  Das würde man aber nicht als unterdrückte Exception machen, sondern als Ursache, das heißt, man würde den Exception-Chaining-Mechanismus verwenden, den es schon seit Java 1.4 gibt.

void method() throws Exception1, Exception2 {
  try (Resource r = new Resource()) {
     ... does something useful that may raise an exception ...
  } catch (Exception1 initialExc) {
     ... does cleanup and re-throws initial exception ...
     throw initialExc;
  }
  catch(Exception2 initialExc) {
     ... handle exception ...
  }
  catch(Exception3 initialExc) {
     ... re-map exception ...
     throw new Exception4(initialExc);
  }
  finally {
     ... final work – no exceptions ...
  }
}

Ursache vs. Unterdrückung

Eine unterdrückte Exception wird automatisch erzeugt im Zusammenhang mit dem neuen try-with-resources-Konstrukt. Man kann weitere unterdrückte Exceptions selber hinzufügen mit Throwable.addSuppressed() .  Eine Exception kann also beliebig viele unterdrückte Exceptions enthalten.  Unterdrückte Exceptions entstehen "gleichzeitig" und gehören zur selben Fehlersituation; es handelt sich um einen initialen Fehler und seine Folgefehler.

Eine Ursache hingegen entsteht beim Abbilden einer Exception auf eine andere Exception.  Das ist der Exception-Chaining-Mechanismus, den wir schon seit Java 1.4 kennen und der in geschichteten Architekturen häufig vorkommt.  Die Exception-Kette entsteht nie automatisch, sondern sie muss ausdrücklich hergestellt werden mit Throwable.initCause() oder durch die Benutzung des Exception-Konstruktor.  Dabei enthält jede Exception nur genau eine Ursache, die wiederum genau eine Ursache enthält, usw.  Die Ursachen entstehen "nacheinander" und beschreiben eine Abbildungskette über einen Call-Stack hinweg.
 

Zusammenfassung und Ausblick

Literaturverweise

Die gesamte Serie über Java 7:

If you are interested to hear more about this and related topics you might want to check out the following seminar:

Seminar   Effective Java - Advanced Java Programming Idioms  4 day seminar ( open enrollment and on-site)