Java 7 – try mit AutoClosables, try(Ressource res), Type Inference

Die erste Frage, die ich mir heute morgen gestellt habe, wie komme ich drauf, dass ich Ende 2015 Beiträge über Java 7 veröffentliche…naja ich komme jetzt gerade erst dazu, mich damit zu beschäftigen, leider…

AutoCloseable – ein Interface, das mit Java 7 eingeführt wurde, es fordert die Implementierung einer Methode … schrecklich überraschend … close() … ein. Zudem kann ich nun Ressourcen im Kopf des try-Blocks deklarieren, der Vorteil hier ganz klar; Egal, ob die try-Anweisung vollständig abläuft oder abrupt  endet, die close()-Methode von Ressourcen, die das Interface AutoClosable implementieren werden definitiv aufgerufen. So können Socket, Filehandles oder Reader-Ressourcen automatisch beendet werden, auch dann wenn eine Exception auftritt. Es können zudem mehrere Ressource ; separiert im try instanziiert werden, bspw.:

Hingewiesen sei auf das rot-markierte Semikolon nach der zweiten Ressourcen, dieses ist optional und kann ja nach Belieben gesetzt oder nicht gesetzt werden. Ein weiterer Vorteil ist, dass zur Laufzeit bekannt ist, welche Ressourcen bereits geschlossen worden sind. Das bedeutet, tritt ein Problem bei der Instanziierung von r2 auf, so wird nur r1 automatisch geschlossen, da dies für r2 nicht notwendig ist.

Aber in dem kurzen Codeblock ist noch mehr, das so nicht ganz so einfach mit Java 6 ging. Genau…die Exceptions…ein Pipe-Symbol/logisches ODER…Das ganze nennt sich Exception-Chaining. Wenn wie in diesem Beispiel drei Exceptions die gleiche Art der Behandlung haben, können die Blöcke auf o.g. Weise zusammengefasst werden…auch wieder sehr praktisch.

Zu guter letzt möchte ich noch weiter auf die Optimierungen beim Entwickeln eingehen. Seit Java 7 können in Variablendeklarationen von Generics die typisierenden Argumente beim Konstruktor-Aufruf weggelassen werden, also statt:

Können wir die verkürzte Schreibweise verwenden:

Die Kombination aus den beiden spitzen Klammern ‚<>‘ wird auch als Diamond bezeichnet. Zusammengefasst kann der Diamond den parametrisierten Typ des Konstruktors einer generischen Klasse ersetzen. Das Weglassen des Diamonds ist bei der Instanziierung nicht erlaubt, weil sonst (in diesem Fall) der Raw-Type der Hashmap angenommen und nicht der generische Typ angenommen wird.

Empfohlen wird zudem der Einsatz ausschließlich bei der Instanziierung von Variablen, nicht in Funktionsaufrufen, auch wenn dies theoretisch möglich ist.

Java7 – Neuerung – Danke!

Heute … gestern … und auch der Tag davor – so fühlt es sich zumindest als Java-Entwickler oftmals an, wenn man mal wieder in die Situation kommt, equals() und hashCode()-Methoden in einem Objekt zu implementieren.  So führt der traditionelle Weg am Referenzvergleich, null-Check und am Ende an diversen if() ..elseif()-Checks vorbei. Diese als „verbose“ (langatmige) Implementierung kennt jeder. Etwas schicker geht es mit den ternären Operatoren (zur Erinnerung: ‚wenn ? dann : sonst‘). Obi Ezechukwu hat uns dann mit seinem compactEquals weitergeholfen, als er seine compactEquals()-Methode vorgestellt hat; er fügt die zu vergleichenden Members der zu vergleichenden Objekte einem Array hinzu,  und nutzt Arrays.equals(Object,Object). Ein ähnlich umständliches Verfahren wird bekannterweise auch für der Überschreiben der hashCode()-Methode eingegangen, was ja notwendig ist, wenn die equals()-Methode eines Objekts überschrieben wird.

IDEs wie IntelliJ, Netbeans und Eclipse helfen natürlich bei der automatischen Erstellung der Methoden in altertümlichem Sinne, was den Stil allerdings auch nicht schöner macht.

Mit der Einführung von Java7, können equals() und hashCode() nun recht komfortabel, objektweise erstellt werden.

 

 

Hingewiesen sei hier auch noch auf die deepEquals()-Methode der Objects-Klasse.

 

Quellen: http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html