Das Interesse an Java scheint auch zehn Jahre nach seiner Veröffentlichung ungebrochen. Mit über 4,5 Millionen Entwicklern zählt es heute zu den verbreitetsten Programmiersprachen der Welt. Die seit letztem Jahr verfügbare Version 5.0 der Java 2 Standard Edition (J2SE) wurde laut Sun Microsystems inzwischen 15 Millionen Mal heruntergeladen. Allerdings sind die Arbeiten an der Java-Plattform mittlerweile so vielfältig geworden, dass der Hersteller für dieses umfangreiche Update fast drei Jahre benötigte. Sun will daher kürzere Release-Zyklen einführen und Updates etwa alle 18 Monate bereitstellen. Auf der diesjährigen Javaone in San Francisco gab Sun einen Ausblick auf die künftigen Java-Versionen "Mustang" und "Dolphin". Mustang folgt demnach auf J2SE 5.0 und erhält gemäß neuer Nomenklatur den Namen "Java Platform, Standard Edition 6" (kurz: "Java SE 6"). Deren Nachfolger Dolphin wird als "Java SE 7" geführt. Auf Basis der aktuellen J2SE wird zudem die Java Enterprise Edition 5 (Java EE) entstehen, die unter anderem die Spezifikation 3.0 für Enterprise Javabeans (EJB) umsetzt. Danach wird es vermutlich auch die Versionen Java EE 6 und Java EE 7 parallel zu Mustang und Dolphin geben. Hierüber sind allerdings noch keine Details bekannt.

Unter den zahlreichen Neuerungen für Mustang spielt die Integration von Skriptsprachen eine wichtige Rolle. Der dazugehörige Spezifikationsvorschlag (Java Specification Request 223 = JSR 223) definiert ein Framework, das es Skriptsprachen ermöglicht, auf Informationen zuzugreifen, die in der Java-Plattform zur Verfügung stehen. Diese Funktion ist bereits ab dem "Build 40" in die Mustang-Version von Java SE integriert. Außerdem soll eine Java Script Engine aufgenommen werden, die auf der "Mozilla"-Implementierung "Rhino" basiert. Weitergehende Pläne sehen zudem die Integration einer von Skriptsprachen unabhängigen Scripting Shell für Mustang vor. Diese wäre für Entwickler sehr nützlich, da sie bei der Prototypenentwicklung und bei Codetests ebenso helfen könnte wie zum Kennenlernen neuer APIs. Wann die Shell kommt, ist aber noch offen.

Ein wichtiger Trend, den Java-Entwickler beachten müssen, ist das Entstehen von Programmier- und Skriptsprachen, die auf der Java Virtual Machine (JVM) laufen können und eventuell auch die JSR 223 als Schnittstelle verwenden. So hat Sun für das Dolphin-Release angekündigt, neue JVM-Software-Bytecodes für andere Sprachen einzubinden, was eine bessere Unterstützung für dynamische Sprachen wie "Groovy" bedeuten würde. Gleichzeitig gibt es Überlegungen, weitere Skriptsprachen zu unterstützen und zusätzliche Scripting Engines direkt in die Plattform zu integrieren. Eine Engine, die gute Chancen hätte, in die neue Java-Version einzufließen, ist die "Beanshell".

Derzeit ist Groovy der wichtigste Vertreter unter den Neuzugängen. Sie ist eine Skriptsprache für die JVM und wird im Java Community Process unter dem JSR 241 spezifiziert. Groovy soll laut ihren Autoren das Schreiben von Skripten und Anwendungen für die JVM schnell und einfach gestalten, weil es Spracheigenschaften bereitstellt, die aus Python, Ruby und Smalltalk bekannt sind. Auf der anderen Seite wird aber eine Java-ähnliche Syntax verwendet. Da Groovy auf der J2SE basiert, können Groovy-Anwendungen deren APIs verwenden und lassen sich auch mit anderen Packages und Anwendungen integrieren, die in Java entwickelt wurden. Eine andere Sprache, die auf lange Sicht als möglicher Kandidat für die Java-Plattform in Frage käme, ist "Fortress". Sie soll wissenschaftlichen Zwecken dienen und wird derzeit in den Labors von Sun entwickelt. Obwohl Fortress von "Secure Fortran" abstammt und ähnliche Aufgaben wie Fortran abdecken soll, hat die Sprache mit Fortran nur wenig gemein.

Veränderungen stehen für Entwickler auch im Enterprise-Bereich ins Haus. Während die J2SE 5.0 schon länger verfügbar ist, lässt die Endfassung der entsprechenden Enterprise Edition (Java EE 5) noch auf sich warten. Wichtigste Neuerung wird hier die Umsetzung des EJB-3.0-Standards sein. Sie soll die von vielen Programmierern als zu komplex kritisierte Entwicklung von Enterprise Javabeans (EJBs) vereinfachen helfen. Bisher bestand das Problem vor allem darin, dass man als Entwickler mehrere Komponenten-Interfaces und mehrere unnötige Callback-Methoden und Exception Handler implementieren musste und immer ein komplexer und fehleranfälliger Deployment Descriptor erforderlich war. Es gibt zwar inzwischen viele Entwicklungsumgebungen, die in der Lage sind, mit Hilfe von Assistenten alle benötigten Artefakte automatisch zu generieren, trotzdem ist das Ergebnis in vielen Fällen sehr unübersichtlich. Gelingen soll die Vereinfachung unter anderem durch die Unterstützung von "Plain Old Java Objects" (Pojos) und die extensive Nutzung von Annotations, die bereits in der J2SE 5.0 eingeführt wurden. Hiermit ist eine Art attributorientiertes Programmieren möglich, indem im Code Zusatzinformationen eingefügt werden, die dem EJB-Container während der Laufzeit Auskunft über die Eigenschaften der Pojos geben. Außerdem werden mit EJB 3.0 neue APIs und Frameworks bereitgestellt.

Die Pojos kommen

Entwickler mussten aus diesen Gründen bei der Arbeit mit den aktuellen EJB-Spezifikationen 2.1 schon für einfache Anwendungen sehr viel Aufwand betreiben, während in der EJB-3.0-Welt alle Objekte Pojos entsprechen, die mit Annotations versehen sind. Letztere helfen das Business-Interface der EJB, das O/R- Mapping sowie Ressourcenreferenzen zu definieren. Annotations lassen sich für Variablen, Methoden, deren Parameter, Aufzählungen, Interfaces, Klassen und Packages einsetzen und sind über ein API erreichbar. Alles, was früher durch "Deployment-Descriptoren" und Home-Interfaces definiert wurde, können jetzt Annotations übernehmen. Das Business-Interface kann nun vom Container automatisch generiert werden. Auch die geplanten "Entity Beans" sind künftig einfache Pojos, die um einige Annotations ergänzt werden, und nicht automatisch persistente Entities.

Arbeitserleichterung

Allerdings werden komplexe EJB-Projekte auch mit den Neuerungen weiterhin umfangreiche Detailkenntnisse erfordern, um eine skalierbare und performante Architektur zu schaffen. Der Einsteiger kann sich jedoch durch den Einsatz von Pojos leichter an das komplexe Thema herantasten. Dies ist vor allem deshalb möglich, weil in vielen Fällen Standardwerte vom Container vorgegeben werden und weiterhin benötigte Interfaces automatisch nach einem Standardschema generiert werden. Möchte ein Entwickler selber Einfluss auf diese Parameter nehmen, kann er das zum größten Teil mit Hilfe der Annotations erledigen. Der Weg über Deployment-Descriptoren und Interfaces wird aber auch weiterhin unterstützt.

Mit EJB 3.0 wird zudem das bisherige Persistenzmodell komplett ausgetauscht. Wurden bislang mit den in JSR 243 spezifizierten "Java Data Objects" (JDO) und dem EJB-Persistenzmodell zwei unterschiedliche Techniken parallel verwendet und weiterentwickelt, so hat Sun sie nun in einem neuen Persistenzmodell vereint, das sich stark am Open-Source-Projekt "Hibernate" orientiert. JDO wird damit künftig an Relevanz verlieren und der neue, im Rahmen der JSR 220 spezifizierte Persistenzmechanismus sowohl für Java SE als auch Java EE zum Einsatz kommen. In der Java-Gemeinde löste der Wechsel zum neuen Persistenzmodell anfangs heftige Diskussionen aus. So müssen sich viele Entwickler jetzt umstellen, und auch bestehende Architekturen sind anzupassen oder zu überdenken, wenn sie weiterentwickelt werden müssen. Inzwischen scheint die neue Ausrichtung aber allgemein akzeptiert zu sein, zumal ein gemeinsamer Standard langfristig Vorteile für alle Beteiligten bringt. Im Rahmen des JSR 243 wird künftig nur noch die Version 1.0.1 der JDO-Spezifikation weitergepflegt und die Abfragesprache JDQL an die neue Pojo-Persistenz angepasst.

XML für den Java-Client

Ein heißes Thema zeichnet sich mit der Integration von XML und Web-Services in die Java SE ab. Bereits mit Mustang ist geplant, den Client-Support für Web-Services künftig mit Hilfe des "Web Services Basic Profile" bereitzustellen. Viele der geplanten Features existieren bereits in J2EE und sollen nun zum Teil auch auf die Client-Plattform übergehen. Dies hat für Entwickler den großen Vorteil, dass sich mit Hilfe von Java-Anwendungen und Java Applets einfach auf Web-Services zugreifen lässt. Bisher hatten viele Entwickler für entfernte Methodenaufrufe auf den Server Protokolle wie Remote Methode Invocation (RMI) oder Corba-IIOP eingesetzt.

Der Aufruf von "Remote Web Services" war bisher hingegen nur mit proprietären APIs möglich, die dann zusammen mit der Anwendung oder dem Applet ausgeliefert werden mussten. In Mustang hingegen ist die Unterstützung von Web-Services Teil der Plattform und muss nicht zusammen mit der Anwendung bereitgestellt werden. Dies hat den Vorteil, dass der Code für das "Java API for Remote Procedure Calls" (JAX-RPC), mit dem sich XML-basierende Methodenaufrufe vornehmen lassen, nicht mehr in dem Applet enthalten ist, sondern nur noch von diesem aufgerufen wird und somit das Applet seine Kompaktheit nicht verliert. Im Gegensatz zum häufig eingesetzten RMI hat die Web-Services-Anbindung den Vorteil der höheren Interoperabilität zwischen verschiedenen Plattformen. Es ist dann nicht mehr relevant, ob sich auf dem Server eine Java- oder eine .NET-Implementierung befindet.

Trotz des Fokus auf Web-Services am Client wird Mustang aber auch einen einfachen, leichtgewichtigen HTTP-Server für Callbacks bereitstellen. Alle übrigen JSRs, die künftig Teil der Plattform werden, sind hingegen bereits im Java Community Process spezifiziert oder durchlaufen diesen. Hierzu gehört das in JSR 224 spezifizierte "Java API for XML-Web Services" (JAX-WS) 2.0, das JAX-RPC 1.0 ablöst und um neue Spezifikationen und Updates zu bestehenden Standards erweitert. Mustang wird aber voraussichtlich nicht die komplette Implementierung, sondern lediglich die Client- und die Core-APIs aufnehmen. Die "Service APIs", die die Grundlage für die JAX-WS Services bilden, bleiben somit außen vor.

XML auf dem Vormarsch

Ein wichtiger Bestandteil der künftigen Web-Service-Infrastruktur von Mustang ist die in JSR 222 spezifizierte "Java Architecture for XML Binding" (JAXB) 2.0. Sie erweitert die bisherige Version 1.0 erheblich, indem sie im Gegensatz zu dieser auch XML-Schema sowie das Binden von Java-Klassen mit XML-Schema unterstützt. Dies ist unter anderem notwendig, um die Data-Binding-Anforderungen von JAX-WS 2.0 zu erfüllen. Als unterstützende APIs stellt Mustang außerdem noch das "XML Digital Signature API" (JSR 105) sowie ein Update zum "Java API for XML Processing" (JAXP) inklusive dem "Streaming API for XML" (JSR 173) bereit. Noch verheißungsvoller bezüglich der XML-Unterstützung ist allerdings das Dolphin-Release von Java. Es soll eventuell den XML-Support direkt in die Java-Sprache integrieren. Dadurch ließe sich in Java direkt mit XML-Literals arbeiten, und es wäre möglich, XML-Strukturen auf Sprachebene zu manipulieren, ohne Methodenaufrufe zu benötigen. (as)