Die 7 Änderungen in Java 7 gegenüber Java 6

Die 7 Änderungen in Java 7 gegenüber Java 6

Manchmal sind Änderungen so unscheinbar, dass man kaum sagen kann wie umfangreich sie waren geschweige wann sie stattgefunden haben. Hier sind die Änderungen welche die Sprache Java mit der Version 7, wie schon auf der Seite Java Programming Language Enhancements in bestem English beschrieben, erneut in eigener Formulierung aufgeführt.

  1. Binary Literals:
    Ließen sich die Literale zu byte, short, int, und long bisher nur dezimal oder hexadezimal schreiben so ist nun auch die binäre Schreibweise möglich.
    Bisher:

    byte dezimal = 16;
    byte hexadezimal = 0x10;
    Neu:
    byte binär = 0b0010000;
    Insbesondere wenn die Typen für Vergleiche auf Bit-Ebene herangezogen werden ergeben sich klarere Schreibweisen.
    byte Bit_0_Flagge = 0b0000001;
    byte Bit_1_Flagge = 0b0000010;
    byte Bit_2_Flagge = 0b0000100;

  2. Underscores in Numeric Literals:
    Muss ein von der Kreditkartenindustrie gefördertes Feature sein. In Numerischen Werten lassen sich nun Unterstriche einstreuen. Somit lassen sich vielstellige Nummern wie:

    long kreditKartenNummer = 1234567890123456L;
    optisch unterteilen,
    long kredit_Karten_Nummer = 1234_5678_9012_3456L;
    Und es gilt:
    (kreditKartenNummer == kredit_Karten_Nummer) //true
    

  3. Strings in switch Statements:
    Bisher musste die Expression im SwitchStatment vom Typ: char, byte, short, int, Character, Byte, Short, Integer oder enum sein. Mit Java 7 kann sie darüber hinaus auch vom Typ: String sein. Damit ist dieses Konstrukt möglich:

    String what = "Foo";
    switch (what) {
    case "foo":
    doFoo();
    break;
    case "bar":
    doBar();
    break;
    default:
    doDefault();
    break;
    }
    Bei der Auswertung der Expression wird String.equals ausgewertet. D.h. es sind zwei Dinge zu beachten:

  4. Ist die Expression null so wird eine NullPointerException geworfen.

  5. Die Auswertung der Expression is case sensitive, es wird also die Groß-und Kleinschreibung beachtet.

  6. Type Inference for Generic Instance Creation:
    Aus

    Map<String, List<String>> myMap =
    new HashMap<String, List<String>>();
    wird
    Map<String, List<String>> myMap = new HashMap<>();
    wobei das Setzen des diamond Operators “<>” in so fern wichtig ist, dass damit explizit Bezug auf die generische Variante von HashMap genommen wird. Ohne diamond Operator
    Map<String, List<String>> myMap = new HashMap();
    beschwert sich der Compiler, dass die Type conversion von HashMap nach Map<String, List<String>> ungeprüft sei und ausserdem dass HashMap ein raw Type sei und diese besser mit entsprechenden Typen zu parametrisieren sei.

  7. Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods:
    Generics sind eingeführt worden um Typsicherheit in Java zu erhöhen. Schon der Compiler soll erkennen können ob eine Zuweisung Typenkonform ist oder nicht. Dennoch ist es nach wie vor möglich eine ClassCastException an Stellen herbeizuprogrammieren, die der Compiler für absolut unbedenklich hält:

    List l = new ArrayList<Number>(); //Hinweis auf raw type
    List<String> ls = l; //Warnung: unchecked conversion
    l.add(0, new Integer(42)); //Hinweis auf raw type
    String s = ls.get(0); //ClassCastException
    
    Der Umstand der in zweiten Zeile herbeigeführt wird, nämlich, dass die Variable ls vom generischen Typ List auf einen nicht generischen Typ zeigt, wird Heap Pollution bezeichnet. Ein weiterer nicht offensichtlicher Ort, an dem Heap Pollution gerne auftritt sind Methoden mit Typisierten Varargs:
    public static <T> void addToList (List<T> listArg,
    T... elements) {
    for (T x : elements) {
    listArg.add(x);
    }
    }
    Java 7 zeigt dort nun eine Warnung an:
    warning: [varargs] Possible heap pollution from parameterized vararg...
    Details und Codebeispiele dazu: Improved Compiler Warnings and Errors When Using Non-Reifiable Formal Parameters with Varargs Methods

  8. The try-with-resources Statement:
    Wesentlicher Punkt ist hier, dass man mit diesem Konstrukt das saubere Schließen von resources ermöglicht. Man beachte den Ausdruck in Klammern der dem try folgt:

    static String readFirstLineFromFile(String path) throws IOException {
    try (BufferedReader br = new BufferedReader(new FileReader(path))) {
    return br.readLine();
    }
    }
    Die Variable br im try-with-resources Statment ist vom Typ BufferedReader und implementiert java.lang.AutoCloseable. Mit Java 7 wird nun sicher gestellt dass die Resource br am Ende der Methode geschlossen wird.

  9. Catching Multiple Exception Types and Rethrowing Exceptions with Improved Type Checking:
    Releativ eingängig, nun kann man in einem try Statment 2 catch Clauses

    catch (IOException ex) {
    logger.log(ex);
    throw ex;
    catch (SQLException ex) {
    logger.log(ex);
    throw ex;
    }
    zu einer zusammenfassen:
    catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
    }
    Die Schärfe der CatchClause bleibt erhalten nur die Schreibweise wird kompakter.

Insgesamt hat sich die Sprache Java mit der Version nicht wesentlich gewandelt. Es ist ein wenig syntactic suggar hinzugekommen. An anderer Stelle ist die, man mag es kaum sagen, Nutzer- bzw. Programmierer-Führung verbessert worden.

Das soll uns nicht vom Programmieren abhalten,

frohes Schaffen!

java