Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

27.06.2003 - 

Umfangreiche Sprachänderungen in der Version 1.5

Einfacheres Java soll .NET-Entwickler ködern

MÜNCHEN (ws) - Die unmittelbar bevorstehenden Updates von Java in der Standard- und Enterprise-Edition (J2SE und J2EE) bringen vornehmlich Neuerungen auf dem Server. Die darauf folgenden Versionen 1.5 hingegen sollen Java wesentlich vereinfachen und damit Visual-Basic-Entwickler zum Umstieg bewegen.

Sun Microsystems erhebt mit Java den Anspruch, eine End-to-end-Plattform anzubieten, die sich von Klein- und Mobilgeräten über PCs bis hin zu Mainframes erstreckt. Um dieser Aufgabe gerecht zu werden, liegt Java schon seit längerem in drei Ausführungen vor: der Java 2 Standard Edition (J2SE), der Enterprise Edition (J2EE) für Server-Anwendungen und der "Micro Edition" für Kleingeräte (J2ME). Sowohl die große als auch die kleine Variante hängen von der J2SE ab, entweder weil sie diese erweitert (J2EE) oder nur eine Teilmenge davon anbietet (J2ME).

Im Java-Fahrplan fungiert die Standardausführung daher als Schrittmacher, indem sie neue Basistechnologien und Sprachfeatures in die Plattform einbringt und damit für J2EE sowie J2ME zugänglich macht. Aufgrund dieser Konstellation erfolgen Updates für die drei Java-Varianten normalerweise nicht gleichzeitig.

Derzeit weist J2SE die Versionsnummer 1.4.1 auf, während die aktuelle J2EE bei 1.3 steht. Die Java-Roadmap sieht daher als nächstes größere Neuerungen bei der Server-Version vor, die in Kürze als Ausgabe 1.4 (siehe Kasten "Was ist neu in J2EE 1.4?") erscheinen soll. Demgegenüber macht J2SE 1.4.2 nur kleine Fortschritte (http://java.sun.com/j2se/1.4.2) und dient primär der Produktpflege. Unübersichtlicher zeigt sich der Fahrplan für J2ME, da es sich dabei nicht um eine einzelne Spezifikation handelt. Vielmehr trägt Sun der Vielfalt an Kleingeräten Rechnung, indem Hersteller mehrere Konfigurationen und Profile kombinieren und um eigene Klassenbibliotheken erweitern können. Bedeutsame Fortschritte erfolgen dort auf Basis von Einzelkomponenten wie der Virtual Machine oder von Profilen. Dieser Ansatz führte zu einer erheblichen Fragmentierung von J2ME, die Sun nun mit der Initiative "Java Technology for the Wireless Industry" (JTWI) in den Griff bekommen möchte.

Enterprise-Features bisher im Vordergrund

Die letzten größeren Java-Updates verfolgten hauptsächlich das Ziel, die Plattform zu konsolidieren und ließen die Sprache selbst weitgehend unverändert. Immerhin hatten sich durch die zeitweise rasante Weiterentwicklung der Technologie einige Inkonsistenzen und Altlasten gebildet, die ihrer Beseitigung harrten. Derart grundlegende Eingriffe, die Java generalüberholen und für neue Entwicklergruppen öffnen soll, stehen mit den Versionen 1.5 von J2SE (Codename "Tiger") und J2EE 1.5 ins Haus. Auf der diesjährigen Konferenz JavaOne, die Sun Mitte Juni in San Francisco abhielt, gab die Company einen Ausblick auf die neuen Features, die diese Ausführungen bringen werden.

Mit den geplanten Änderungen zielt Sun vor allem darauf ab, die Benutzung von Java einfacher zu machen. Diesem Vorhaben liegt die Einschätzung zugrunde, dass die hauseigene Technologie mittlerweile ein hohes Maß an Robustheit, Skalierbarkeit sowie Performance bietet und daher nun andere Prioritäten gesetzt werden können. So behaupteten Keynote-Sprecher auf der JavaOne, dass Testinstallationen in den firmeneigenen Laboren mehr als 100 CPUs nutzen und einen Heap-Speicher von über 500 GB verwalten könnten. Bei Firmen wie Sun, die ihr Geschäft primär auf das obere Segment von Enterprise-Anwendungen ausrichten, liegt eine Konzentration auf derartige Merkmale nahe. Dies gilt nicht nur für die Unix-Company, sondern auch für andere Anbieter aus dem Java-Lager wie IBM oder Oracle. Erfinder James Gosling bekannte bereits des Öfteren, er habe beim Design von Java besonders darauf geachtet, dass die Technologie den gehobenen Ansprüchen von Sun-Anwendern gerecht werde. Dabei räumte er ein, dass der Aspekt der Benutzerfreundlichkeit zu kurz gekommen sei und Java den Ruf erworben habe, kompliziert zu sein.

Sun reagiert auf .NET-Konkurrenz

Die geplante Kurskorrektur verdankt sich indes nicht bloß einer neu entdeckten Solidarität mit Programmierern, denen das Leben leichter gemacht werden soll. Vielmehr reagiert das Java-Lager damit auf die Herausforderung durch Microsofts .NET. Die Technologie aus Redmond beruht zu großen Teilen auf Konzepten von Java, allerdings konnte Microsoft seine mehrjährigen Erfahrungen als Java-Lizenznehmer nutzen und einige Verbesserungen in das eigene System einbringen. Nach allgemeiner Auffassung zählen ein flexibles Metadatenkonzept, die Unterstützung für mehrere Programmiersprachen sowie der Einsatz von Web-Services zu Microsofts Innovationen. Darüber hinaus gilt die dazugehörige Entwicklungsumgebung "Visual Studio .NET" als eines der besten Programmierwerkzeuge am Markt.

In der Konkurrenz mit Java hält Microsoft zwei weitere Trümpfe in der Hand: die große Gemeinde der Visual-Basic-Entwickler sowie das Bundling eines kompletten Applikations-Servers mit Windows. Als interessant erweist sich diese Kombination besonders bei Anwendungen für die Abteilungsebene sowie für mittelständische Firmen. Mit den beabsichtigten Neuerungen will Sun die eigene Technologie ausdrücklich für dieses Segment attraktiver machen. Redner auf der JavaOne wiesen auf die Lücke hin, die bei Java zwischen den großen Enterprise-Anwendungen und der inzwischen weit verbreiteten Nutzung auf mobilen Kleingeräten klaffe.

Innerhalb des Java-Lagers versuchen einige Hersteller durch besonders benutzerfreundliche Tools dieser Problematik zu begegnen. So bezieht sich etwa Bea mit seinem "Weblogic Workshop" explizit auf Visual Basic als Vorbild und will damit Programmierer von Microsoft abwerben. Sun präsentierte auf der Java-Konferenz mit "Rave" die Vorabversion eines ebenfalls visuellen Tools, das die formularbasierende Entwicklung von Web-Anwendungen erlauben soll.

Allerdings herrscht bei Sun Klarheit darüber, dass komfortable Werkzeuge alleine das Problem nicht lösen können. Sie kommen nämlich primär den Entwicklern von einfacheren Anwendungen entgegen und eignen sich weniger für große Projekte - aber auch dort wäre eine Reduktion unnötiger Komplexität von Vorteil. Außerdem werden Entwickler auch bei bequemen Tools früher oder später mit Code konfrontiert. Unnötige Komplexität wird dann wieder zum Problem. Deshalb soll J2SE 1.5 die größten Änderungen der Sprache selbst bringen, seit die Technologie 1995 auf den Markt kam (siehe Kasten "Der Tigersprung").

Einheitliches Metadatenkonzept

Besondere Bedeutung kommt dabei dem neuen Metadatenkonzept zu, das an jenes von .NET angelehnt ist. Es erlaubt Entwicklern, Klassen, Methoden und Felder mit Anmerkungen zu versehen. Diese geben etwa Auskunft darüber, ob eine Methode als Web-Service abrufbar ist, oder ob eine Komponente transaktionssicher sein muss. Bisher nutzte Java mehrere unterschiedliche Konzepte für derartige Zwecke. So existiert etwa eine Namenskonvention für Methoden, die in Javabeans nach außen sichtbar sein sollen und den Wert von Instanzvariablen abrufen beziehungsweise verändern können. Sie werden mit dem Präfix "get" oder "set" versehen. Daneben kennt Java aber auch den Mechanismus der Marker-Interfaces, die keine Methoden enthalten, sondern nur dazu dienen, Klassen mit Attributen wie "serializable" zu versehen. Nicht zuletzt ist eine weitere Art von Metadaten dazu gedacht, Java-Anwendungen während ihrer Laufzeit mit Informationen zu versorgen. Es handelt sich dabei um die so genannten Deployment Descriptors, die im XML-Format vorliegen und außerhalb des Quellcodes vorgehalten werden. Ab der Version 1.5 sollen diese unterschiedlichen Mechanismen durch ein einheitliches Verfahren abgelöst werden. Die Deskriptoren sollen dann zwar erhalten bleiben, aber automatisch aus den neuen Metadaten erzeugt werden.

Auch J2EE soll einfacher werden

Die für J2SE 1.5 geplanten neuen Sprachfeatures gehen natürlich in die später erscheinende J2EE 1.5 ein. Dort sollen sie auch dazu beitragen, die als kompliziert verschrienen Transaktionskomponenten Enterprise Javabeans (EJBs) zu vereinfachen. In der Version 3.0, die voraussichtlich Bestandteil von J2EE 1.5 sein wird, soll es möglich sein, simple EJBs zu schreiben, die wie gewöhnliche Klassen aussehen. Die Markierung von Methoden als "home" oder "remote" erfolgt dann über Metadaten, zudem schirmen sie Entwickler von Deployment Descriptors ab.

Zu J2EE 1.5 wird auch das API für den Datenbankzugriff (JDBC) in der Version 4.0 gehören. Dafür kündigte Sun ebenfalls Veränderungen zugunsten einfacherer Nutzbarkeit an. Dazu zählen etwa ein automatisches Treiber-Management und ein simplerer Verbindungsaufbau zu Datenquellen. Einmal mehr sollen hier die neuen Metadaten Entlastung für den Programmierer bringen und beispielsweise einfache SQL-Statements repräsentieren können. Die vielfältigen Einsatzmöglichkeiten derartiger Attribute ließ aber bereits warnende Stimmen laut werden (http://www.theserverside.com/resources/articles/JavaOneDayThree_03/article.html). Sie befürchten den Missbrauch dieses Mechanismus und dadurch eine schlechtere Lesbarkeit von Java-Code. Insgesamt stärkt das neue Metadatenkonzept aber den deklarativen Aspekt innerhalb der stark imperativen Sprache Java.

Der Mehrsprachigkeit von .NET, die als ein weiterer Vorteil gegenüber Java gilt, versucht Sun im Rahmen des Java Specification Request (JSR) 223 (http://www.jcp.org/en/jsr/detail?id=223) zu begegnen. Ziel der Initiative ist es, gängige Scriptsprachen enger mit Java zu integrieren. Dabei geht es nicht wie bei .NET darum, Compiler für möglichst viele Sprachen anzubieten, die Java-Bytecode erzeugen können. Derartige Software gibt es schon und stammt wie "Jython" (http://www.jython.org) zumeist aus der Open-Source-Welt. Ähnliches gilt für eine Reihe von Sprachinterpretern, die in Java geschrieben wurden. Dazu zählen etwa "JBasic" oder die Javascript-Implementierung "Rhino". Dieser Ansatz hat den Vorteil, dass die Sprache nicht an das Objektmodell von Java angepasst werden muss. Dies ist ein häufiger Kritikpunkt an .NET, weil dort einige Sprachen teils erheblich von der ursprünglichen Fassung abweichen. Eine Übersicht über Sprachen für die Java Virtual Machine (JVM) findet sich unter http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html.

Bei dem neuen Vorstoß möchte Sun indes Standards definieren, wie etablierte Scriptsprachen von außen auf Java-Anwendungen zugreifen können. Die Spezifikation wird dafür voraussichtlich ein API auf Basis des Java Native Interface (JNI) festlegen und beschreiben, wie Java-Anwendungen zusammen mit Scriptcode in einem Web-Archiv (WAR) verpackt und auf den Server ausgebracht werden können. Auf der JavaOne gab Sun den Abschluss einer Kooperation mit Zend Technologies bekannt. Die israelische Firma zeichnet für den freien PHP-Interpreter verantwortlich. Entsprechend soll die Anbindung dieser Sprache als Referenzimplementierung dienen. Die Unterstützung für andere populäre Scripttechnologien wie Perl oder Python ist geplant.

Im Vordergrund steht auch hier die Absicht, den Zugang zur Java-Plattform zu vereinfachen. Die Scriptsprachen gelten dabei nicht wie unter .NET als mehr oder weniger gleichberechtigte Alternativen, sondern teilen sich die Arbeit mit Java. Demnach sollte Geschäftslogik bevorzugt in der Sun-Sprache realisiert werden, das simplere PHP würde sich für die Entwicklung von Web-Frontends empfehlen. Auf diese Weise könnten mehr Scriptprogrammierer in Kontakt mit Java kommen und sich - so wohl die Hoffnung von Sun - stärker auf diese Plattform einlassen. Java bietet mit Java Server Pages (JSP) zwar selbst eine Technologie an, die auf die Entwicklung von Web-Oberflächen spezialisiert ist. Diese gilt aber im Vergleich zu PHP als schwierig und soll in der bevorstehenden Spezifikation 2.0 diesbezüglich verbessert werden.

Im Kampf um das untere Marktsegment, also bei Software für die Abteilungsebene und kleinere Firmen, misst Sun dem "Ease of Development" besondere Bedeutung zu. Einer weiteren Möglichkeit, die eigene Plattform dort populärer zu machen, nämlich über das Open-Source-Modell, stehen die Sun-Offiziellen zwiespältig gegenüber. Zwar gewährt der Hersteller diversen Apache-Projekten erhebliche Unterstützung, weist aber alle Forderungen nach entsprechender Öffnung der Kerntechnologie zurück.

Zwiespältige Haltung zu Open Source

Auch auf der diesjährigen JavaOne begründeten Firmenvertreter ihre Haltung damit, dass Microsoft die Kontrolle über ein quelloffenes Java gewinnen und die Plattform durch abweichende Implementierungen fragmentieren könne. Schwer tut sich die Company aber auch mit freien J2EE-Servern wie Jboss (http://www.jboss.org). Schon seit Längerem fordert das Entwicklerteam die J2EE-Zertifizierung seiner Software durch Sun, bis dato kam diese aber nicht zu Stande. Dessen Leitfigur Marc Fleury warnte schon früher in einem Disput mit Scott McNealy (http://www.jboss.org/articles/mcnealy.jsp) vor der Gefahr, dass J2EE zu sehr auf das Hochpreissegment beschränkt bleibe. Open-Source-Implementierungen wie Jboss müssten seiner Meinung nach im Interesse von Sun sein, weil sie den Markt gegen Microsoft nach unten absichern.

Auch wenn sich Sun einer gänzlichen Öffnung von Java widersetzt, so versucht das Unternehmen doch einige bewährte Ansätze des Open-Source-Modells auf Java zu übertragen. Dazu zählt sicher das Bemühen, eine Community zu etablieren. Eine wichtige Rolle spielt dabei der Java Community Process, der zahlreiche Hersteller in die Weiterentwicklung von Java einbindet. Eine neue Initiative startete Sun zusammen mit dem Verlagshaus O''Reilly anlässlich der JavaOne unter der Bezeichnung Java.net. Die Site http://www.java.net soll besonders Programmierer ansprechen und für eine engere Bindung an die Idole der Java-Gemeinde sorgen. Als besondere Attraktion dafür gilt der Weblog (http://weblogs.java.net/jag) von Java-Erfinder James Gosling.

Der Tigersprung

Seit den Anfängen von Java im Jahr 1995 ließ Sun die Sprache selbst weitgehend unverändert. Den größten Eingriff bedeutete die Einführung von Inneren Klassen mit der Version 1.1. Das für Mitte 2004 geplante Release J2SE 1.5 ("Tiger") soll eine Reihe schon länger geforderter Neuerungen bringen. Dazu zählen:

- Metadatenkonzept: Es sieht Anmerkungen zu Klassen, Methoden und Feldern mittels Attributen vor. Ihm kommt eine wesentliche Rolle bei der Entrümpelung von Java zu.

- Generics: Sie sollen für Typsicherheit bei Sammlungen sorgen und explizite Typumwandlungen überflüssig machen.

- Aufzählungstypen: Wie bereits C oder C++ wird Java das Schlüsselwort "enum" erhalten.

- Erweiterte for-Schleife: Zur einfacheren Iteration über Elemente einer Sammlung soll Java eine erweiterte Syntax für for-Schleifen erhalten. Sie entspricht dem "for each" vieler Scriptsprachen.

- Autoboxing: Stark vereinfachte Syntax zur Konvertierung von primitiven Datentypen in die korrespondierenden Hüllenklassen und umgekehrt.

- Statischer Import: Klassen können damit Kon-stanten von Interfaces und anderen Klassen importieren, ohne von ihnen abgeleitet zu sein.

Was ist neu in J2EE1.4?

Web-Services

J2EE 1.4 gilt als das "Web-Service-Release". Die dafür nötigen Technologien und APIs existieren zwar schon länger in der Java-Welt, die neue Spezifikation definiert aber nun die Standards, damit Java-Web-Services über J2EE-Container hinweg portabel sind. Dazu zählen einheitliche Formate für das Verpacken und Ausbringen von derartigen Anwendungen.

Neue Deployment-APIs

Sie sollen sicherstellen, dass alle Java-Anwendungen auf dieselbe Art und Weise auf J2EE-Server verschiedener Hersteller ausgebracht werden. Damit entfällt für Tools-Anbieter die Notwendigkeit, für unterschiedliche Server separate Mechanismen zu entwickeln.

Enterprise Javabeans 2.1

Das EJB-Update bringt vor allem Verbesserungen in der mit Version 2.0 eingeführten Query-Language. Sie erlaubt nun die Sortierung von Abfrageergebnissen und führt weitere vordefinierte Funktionen ein. Ein neuer Timer Service erlaubt zudem den zeitgesteuerten Aufruf von EJBs.

Servlet 2.4

Die neue Servlet-Spezifikation bringt nur geringfügige Veränderungen. So erweitert sie das mit 2.3 eingeführte Filterkonzept und wirft das Single-Thread-Modell über Bord.

Java Server Pages 2.0

JSP 2.0 soll die Entwicklung von Web-Frontends erleichtern. Zu diesem Zweck führt es eine neue Expression Language ein, vereinfacht die Programmierung von Custom Tags und verbessert die XML-Unterstützung.

J2EE Management 1.0

Diese Spezifikation beschreibt Ressourcen von Applikations-Servern, die über System-Management-Tools verwaltet werden sollen und gibt vor, wie dies zu geschehen hat. Sie bietet Abbildungen auf bestehende Verwaltungswerkzeuge und -protokolle wie etwa das Common Information Model (CIM) oder das Simple Network Management Protocol (SNMP).

Connectors 1.5

Die Java Connector Architecture (JCA) definiert einheitliche Schnittstellen, über die sich Konnektoren zu Backend-System in Applikations-Server einklinken lassen. Die neue Version erlaubt die bidirektionale Kommunikation zwischen Java-Programmen und ERP-Anwendungen. Außerdem sieht sie eine Hersteller-übergreifende Verpackung und Ausbringung derartiger Komponenten vor.

Abb: Voraussichtlicher Fahrplan für J2SE

Quelle: Sun Microsystems