Java: Erweiterte Funktionen von JDK 1.5

Sun plant für den Sommer 2004 die Einführung einer umfassenden Überarbeitung der Programmiersprache Java. Diese trägt bislang den Codenamen "Tiger", die offizielle Bezeichnung wird jedoch JDK 1.5 lauten. ZDNet erklärt die neuen Funktionen.

Die neue Version von Java wird die Java Specification Requests 14 und 175 (JSR-14, (JSR-175) umsetzen. Außerdem soll sie erhebliche Verbesserungen in puncto Laufzeit-Performance, Skalierbarkeit, Verwaltbarkeit und Überwachung mit sich bringen.

In diesem Artikel werden einige der neuen Funktionen von JDK 1.5 erläutert, darunter:

  • Generics: Bieten Typsicherheit zur Kompilierzeit für Collections und sorgen dafür, dass nicht bei jeder Entnahme eines Objekts aus den Collections ein Casting erforderlich wird.
  • Erweiterte for-Schleife: Beseitigt Fehleranfälligkeit von Iteratoren.
  • Autoboxing/Unboxing: Keine manuelle Konvertierung zwischen primitiven Typen (wie double) und Wrapper-Typen (wie Double) mehr erforderlich.
  • Typsichere Enumerations: Liefern alle Vorteile des Typesafe enum-Pattern.
  • Statischer Import: Vor der Verwendung der statischen Member-Variablen anderer Klassen müssen keine Klassennamen mehr benutzt werden. Dadurch wird der Code übersichtlicher.
  • Metadaten: Kein Schreiben von wiederkehrenden Informationen mehr erforderlich, ermöglicht deklarative Programmierung.

Im Folgenden werden die genannten Funktionen im Detail beleuchtet und einige Beispiele erörtert.

Generics

Generics sind eines der praktischsten Features von JDK 1.5. Sie ermöglichen Typsicherheit zur Kompilierzeit und wahrscheinlich weniger ClassCastExceptions während der Laufzeit. In JDK 1.5 kann man den Objekttyp festlegen, den eine bestimmte Collection akzeptiert/zurückgibt. In JDK 1.4 ist zum Erstellen einer Liste aus Mitarbeiternamen ein Collection-Objekt wie die folgende Anweisung erforderlich:



In JDK 1.5 würde man die folgende Anweisung verwenden:



Interessant ist hierbei, dass man bei Eingaben, die keinen String darstellen, dies in Kompilierzeit feststellt, so dass man das Problem beheben kann. Ohne Generics würde man einen solchen Bug erst bemerken, wenn der Kunde anruft und angibt, dass das ausgelieferte Programm einen Konflikt mit einer ClassCastException verursacht hat.

Außerdem ist positiv zu erwähnen, dass beim Abruf eines Elements aus der Collection kein Casting erforderlich ist. Statt der folgenden Anweisung:



lautet die Eingabe einfach:



Das Casting von Objekten ohne Kenntnis von deren Typ ist nicht ratsam und kann vor allem zur Laufzeit fehlschlagen. Es könnte zum Beispiel vorkommen, dass der Benutzer versehentlich eine Collection einsetzt, die String-Buffer statt Strings enthält. In Listing A wird der Client zur Eingabe einer String-Collection aufgefordert, was der Compiler nicht erzwingen kann. Listing B zeigt, wie diese Methode mit Generics aussieht.

Nun ist aus der Signatur der Methode klar geworden, dass die Input-Collection nur Strings enthalten darf. Wenn der Client die Eingabe einer Collection aus String-Buffern versucht, führt das Programm keine Kompilierung durch. Außerdem enthält die Methode keine Casts. Sie ist um eine Zeile kürzer und auch übersichtlicher, wenn man sich erst einmal an das Lesen von Generics gewöhnt hat.

Themenseiten: Anwendungsentwicklung, Plattform, Software

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Java: Erweiterte Funktionen von JDK 1.5

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *