Der Tiger ist los

Beim Blick auf die letzten beiden J2SE-Releases mit ihren JDKs 1.3 und 1.4 entsteht der Eindruck, dass Sun bei deren Veröffentlichung eher das Ziel verfolgte, Kritiker aus anderen Welten ruhigzustellen als die Bedürfnisse der Java-Entwickler zu erfüllen. Orientiert man sich an der veröffentlichten Roadmap, so konzentriert sich das neue JDK auf die Bereiche Qualität, Überwachung und Verwaltung, Leistung und Skalierbarkeit, Erleichterung der Entwicklung sowie Desktop-Client. Nach Aussage der Sprachdesigner ist das neue JDK an den Wünschen der Entwickler ausgerichtet - frei nach der Devise: „Weniger Marketing, mehr Development.“ Doch für wie viel mehr Entwicklungskomfort sorgen die etwa 600 neuen oder veränderten Quelldateien der Packages java.* und javax.* wirklich? Grundlage für die folgenden Betrachtungen bildet die Version beta-b-32 des JDK 1.5 aus dem Compatibility and Performance Program, Codename Tiger.

Keine Änderung ohne Antrag. Was sich zunächst nach deutschem Bürokratendschungel anhört, ist die Grundlage jeglicher Änderungen im Umfeld der Java-Spezifikation. Das Mittel zum Zweck ist der Java Community Process (JCP), innerhalb dessen sich Expertengruppen mit der Weiterentwicklung der einzelnen APIs beschäftigen. Der erwähnte „Änderungsantrag“ heißt hier Java Specification Request (JSR).

15 Pakete mit Änderungen

Im Fall von Tiger handelt es sich dabei um den JSR-176 „J2SE 1.5 Release Content“, der 15 weitere JSRs umfasst. Glaubt man allerdings der Dokumentation des aktuellen Build sowie zahlreichen zum Teil widersprüchlichen Aussagen von Sun und in der Fachliteratur, stehen noch einige weitere Kandidaten auf der Liste. Es kann derzeit von mindestens 18 geplanten JSRs (s. „JSRs im JDK 1.5“) ausgegangen werden.

Trotz aller Neuerungen und Änderungen hat sich Sun das Ziel gesetzt, ohne eine Erweiterung des Befehlssatzes der Virtual Machine (VM) auszukommen. Verständlich, wenn man hinter die Kulissen blickt: Sun kann schon lange keine Änderungen mehr an einer JVM (Java Virtual Machine) einführen, die die sprachliche Stabilität und Abwärtskompatibilität gefährden, denn das verursacht hohe Kosten bei anderen Herstellern.

Die wohl tiefgreifendste Neuerung des JDK 1.5 ist die Einführung parametrisierbarer Klassen, (Generics, JSR-014, [1]). Das ist keine bloße Variante der klassischen C++-Templates. Anders als bei der dort üblichen heterogenen Übersetzung, die für jede Template-Instanz eine neue Klasse erzeugt, existiert in Java nur eine einzige Klasse mit erweiterten Typ-Deklarationen. Spezialisierungen generischer Klassen führen zu impliziten Casts, wie Listing 1 an der Klasse List illustriert.

 List<String> list = new ArrayList<String>();
 list.add("Test");
 list.add("Test1");
 // compiletime failure
 // list.add(new Object());

 for (int i = 0; i < list.size(); i++) {
   list.get(i).toUpperCase();
 }

-- Decompilierter Bytecode -- 

 ArrayList arraylist = new ArrayList();
 arraylist.add("Test");
 arraylist.add("Test1");

 for(int i = 0; i < arraylist.size(); i++) {
  ((String)arraylist.get(i)).toUpperCase();
 }

Leider gehen durch dieses Verfahren während der Übersetzung die generischen Details verloren. Neue Methoden der Reflection-API (getGenericInterfaces, getTypeParameters, getGenericSuperclass) gestatten jedoch zur Laufzeit den Zugriff darauf.

Obwohl viel kritisiert, bringt diese schwächere Form parametrisierbarer Klassen für den Entwickler Verbesserungen. So erhöht sich die Lesbarkeit der Quellen, und die nun mögliche Syntaxprüfung durch den Compiler dürfte die Anzahl der ClassCastExceptions reduzieren.

Verbesserte Schleifen sparen Arbeit

Auch die Spracherweiterungen des JSR-201 (Enhanced For Loop, Static Imports, Autoboxing und typsichere Enumerations) sollen den Entwicklungskomfort verbessern. Wie in Listing 2 zu sehen, verkürzen die neuen Schleifen die sonst lästige Iteration über die Elemente einer Collection. Static Imports (Listing 3) ermöglichen den selektiven Zugriff auf Konstanten und statische Methoden anderer Klassen beziehungsweise Interfaces. Willkommen ist ebenfalls das von anderen Sprachen bekannte Autoboxing, das identische Behandlung von Java-Objekten und Primitiven erlaubt: Das lästige Erzeugen von Wrappern beim Arbeiten mit Primitiven entfällt.

-- Beispiel Enhanced For Loop -- 

public void printStringLength(List<String> aList) {
  // enhanced for loop

  for (String entry: aList) {
    if (entry != null) {
      System.out.println("Length " + entry.length());
    }
  }
}

-- Decompilierter Bytecode --

public void printStringLength(List list) {
  Iterator iterator = list.iterator();

  do {
    if(!iterator.hasNext())
      break;

    String s = (String)iterator.next();
    if(s != null)
      System.out.println("Length " + s.length());
  } while(true);
}

-- Beispiel Static Import -- 
import static java.lang.Math.*;
import static javax.naming.Context.*;

...

// accessing java.lang.Math.*
log(1.5);
abs(1.5);

// accessing javax.naming.Context.*
System.out.println(INITIAL_CONTEXT_FACTORY);

-- Decompilierter Bytecode -- 

Math.log(1.5D);
Math.abs(1.5D);

System.out.println("java.naming.factory.initial");

Mehr zu den Neuerungen im JDK 1.5 finden Sie in der aktuellen Printausgabe der iX. (ck)