Die JavaOne-Konferenz ist in jedem Jahr ein Gradmesser für die Akzeptanz von Java. Weiterentwicklungen und neue Systemumgebungen geben zugleich einen Hinweis auf kommende Trends. Nach der ersten Ankündigung der Verfügbarkeit von Java für mobile Endgeräte vor drei Jahren und einer eher zähen Anlaufphase konnte der Besucher diesmal fast den Eindruck gewinnen, Java sei inzwischen zur "lingua franca" der mobilen Welt geworden. Kein Handyhersteller, der nicht auf Java setzt, um mit den kommenden Killer-Applikationen endlich wieder mehr Geräte verkaufen zu können.
Auch balgen sich inzwischen mehr als eine Hand voll Anbieter im Bereich der J2EE-basierenden Applikationsserver. Hier ist die Hoffnung groß, dass sich das Rad der Innovationen durch den internen Konkurrenzdruck bei gleichzeitig offener Architektur weiterhin schnell in Richtung Java dreht. Sun sieht auch Potenzial in der Windows-Welt und so will man alles unternehmen, damit jeder Windows XP-User per Download auf eine vollwertige Java-Engine zugreifen kann.
Nachdem auch der Kurs der Sun-Aktie im letzten Jahr stark ramponiert wurde, stellten sich viele Beobachter die Frage, wie und ob Sun in Zukunft die teure Weiterentwicklung von Java finanzieren kann und will. Auf diesen Punkt angesprochen, stellten sich die Sun-Offiziellen deutlich hinter Java: "Wir bauen auf Java und darauf, dass wir weiterhin viele Server verkaufen, weil unsere Kunden schnelle Server benötigen". Java möchte man also weiterhin quasi als Verkaufsvehikel für die eigenen Server "mit voller Kraft" unterstützen und finanzieren.
Open Source mit mehr Einfluss auf Java
Eine wichtige Vereinbarung stellte Sun-Boss Scott McNeally persönlich während seiner Keynote vor. Nachdem vor Monaten in den Diskussionsforen der Apache-Gruppe unter der Überschrift "Ist Java tot?" eine heiße Diskussion über die zukünftige Offenheit der Sun-Standards für die Open Source-Gemeinde geführt wurde, scheinen die Offiziellen hinter den Kulissen auf die Kritik hinsichtlich der Handhabung des "Java Community Process" (JCP) reagiert zu haben. Innerhalb der JCPs werden neue Java-Standards in Form so genannter JSRs (Java Specification Request) abgewickelt. Gemeinsam mit Jason Hunter, einem aktiven Mitglied der Open Source-Gemeinde (JDOM), stellte McNeally die Änderungen im Prozess vor.
Demnach sollen Open Source-Vertreter noch vor der "public review"-Phase Einsicht in den JSR-Prozess erhalten. Noch wichtiger ist ein Passus, nach dem Open Source-Referenz-Implementationen und -Testumgebungen zu allen künftigen JSRs, beispielsweise unter der Apache-Lizenz, möglich sind. Zudem sei der kostenfreie Zugang eines Open Source-Partners zu der jeweiligen Technologie (allerdings ohne Support) gewährleistet. Auf Nachfrage wurde aber bestätigt, dass die Umstellung der bereits bestehenden JSRs (derzeit knapp unter 200) auf die neue Regelung nicht in jedem Fall möglich sei, da zum Teil Patente und Verträge mit den aktiven Mitgliedern existieren, die sich mit einer offenen Lizenz nicht vereinbaren lassen. Für einige wichtige JSRs, die Technologien wie JAXB, JSP, Servlets, JAXM, JAXR, JAXRPC, Server Faces und J2ME Web Services hat Sun aber explizit eine Änderung der rechtlichen Regelung angekündigt.
Java und Webservices für Mobiltelefone
Die auf der JavaOne allgegenwärtigen Webservices sollen im nächsten Jahr auch für Micro-Edition-Systeme zur Verfügung stehen (JSR-173). Nach einer Review-Phase noch in diesem Jahr peilt Sun den Sommer 2003 für eine erste Release an. Bereits im Juni dieses Jahres will man die erste Release des "Web Services Developers Pack" anbieten. In Kombination mit anderen Java-Technologien (JAXRPC etc.) möchte man der .Net-Plattform des großen Konkurrenten Paroli bieten können. In diversen (und sehr gut besuchten) Vorträgen wurde deutlich, dass man sich hierbei hauptsächlich auf die Serverseite der Webservices stützt, während man auf der Clientseite auch mit der Windows-Welt rechnet.
Vor drei Jahren wurde der Wireless-Markt zum ersten Mal offensiv als zentrales Ziel für die Java-Strategen ausgemacht. Es folgten Ankündigungen und Auslieferung beziehungsweise Lizenzierung der PersonalJava-Plattform auf der Basis der "kleinen" KVM mit vereinzelt angebotenen Applikationen. Es hat zwar länger gedauert als erwartet, doch die diesjährige JavaOne zeigte eindrucksvoll, wie weit die Akzeptanz von Java in diesem Bereich inzwischen geht. Alle wichtigen Hersteller von mobilen Telefonen waren mit Ständen und Vorträgen vertreten. Niemand, der nicht die Wichtigkeit von Java für die mobilen Devices hervorhob.
Zudem zeigte sich, dass kein Hersteller sich in die Abhängigkeit des großen Bruders Microsoft begeben will. So schwenkte das vor Jahren gegründete Parlay-Konsortium (und im Zuge dessen auch das Open Mobile Architecture-Konsortium) mittlerweile offiziell auf die Java-Plattform um, um den Zugang der Handy-Applikationen auf die Netzinfrastruktur der Telcos, und damit das direkte Abrechnen (Provisioning) zu erlauben.
Java 2 ME ersetzt PersonalJava
Und auch auf der Clientseite ist inzwischen ein Trend deutlich: Vergleicht man diesen Markt mit dem PC-Segment, so fallen die sprunghaft ansteigenden Stückzahlen auf. Während die Handy-Industrie im letzten Jahr nach eigenen Angaben noch etwa 14 Millionen Java-fähiger Devices verkaufen konnte, sind es in diesem Jahr nach den Prognosen von Herstellern und Analysten bereits über 100 Millionen Endgeräte. Viele der neu angekündigten Geräte sind von Grund auf Java-fähig. Anbieter wie Nokia setzen konzentriert auf Java, nicht zuletzt, um mit Hilfe der neuen Applikationen endlich wieder mehr Geräte verkaufen zu können.
Neben der erst jetzt stark ansteigenden Verkaufskurve Java-fähiger Geräte hat vor allem die Unsicherheit um den PersonalJava-Nachfolger viele Anbieter von Hard- und Software gebremst. Nach den Ankündigungen von J2ME im letzten Jahr galt PersonalJava als "lame duck", während vom Nachfolger weit und breit wenig zu sehen war. Zur JavaOne konnte Sun wenigstens etwas Licht ins Dunkel bringen.
Details zu Java 2 Micro Edition
Die Java-Gemeinde wartete auf konkrete Aussagen zum Nachfolgersystem von PersonalJava, der J2ME-Plattform, die unter einem Dach sehr stark divergierende Segmente umfasst. Auf der untersten Ebene stellt die "Connected Device Configuration" (CDC) beziehungsweise die "Connected Limited Device Configuration" (CLDC) die Verbindung zur Hardware her. Darauf aufbauend kann ein Anbieter ein oder mehrere so genannte "Profiles" aufsetzen, die jeweils zusätzliche Funktionalität bieten, wobei zum einen die Java-Bibliotheken des darunter liegenden Layers erweitert werden oder komplett neue Pakete hinzukommen.
Während für die eingeschränkte Hardware eines Handys das so genannte "MID Profile" (MIDP) zum Einsatz kommt, sollen moderne PDAs in den Genuss eines "Foundation Profile", "Personal Basis Profile" und Personal Profile" sowie weiterer spezialisierter Profiles (PDA-Profile, Game-Profile) kommen. Eine erste Basisversion ist für das zweite oder dritte Quartal dieses Jahres angekündigt, während spezialisierte Profiles wie PDA-, Game- oder Personal-Profile wohl noch etwas auf sich warten lassen.
Viel Arbeit für Programmierer
Das "Personal Basis Profile" (JSR-129) adressiert hauptsächlich leistungsschwächere PDAs sowie SetTop-Boxen, die typischerweise eine eigens optimierte Oberfläche aufweisen. Aus diesem Grund findet der Programmierer nur wenig AWT- und "Light"-Swing-Komponenten. Statt des Supports von Applets, die ja eine komplette AWT-Umgebung erwarten, spricht man im PBP-Umfeld von "Xlets", die auf einen einzigen Frame zugreifen können und die Lifecycles init(), start(), pause() und destroy() annehmen können. Während einzelne Xlets untereinander mittels "Inter-Xlet-Communication" (IXC) kommunizieren können, läuft jede Applikation in einer eigenen VM. Schwergewichtige Komponenten wie Dialog, Canvas, Panel, Button oder Scrollbar fehlen. Alle bisher als "deprecated" eingestuften APIs fehlen ebenso wie das alte 1.0-Eventmodell. Auch der Java2D-Support hält sich in Grenzen, bietet aber immerhin "Alpha blending", "Alpha Composite" und "Graphics2D".
Das auf dem PBP aufbauende "Personal Profile" (JSR-062) adressiert leistungsfähige PDAs, Webpads oder Internet-fähige SetTop-Boxen. Der API-Set ist direkt von J2SE 1.3.1 (Subset) abgeleitet und unterstützt Applikationen, Xlets und Applets. Die Objekt-Serialisation soll J2SE-kompatibel sein. Die Oberfläche des "PP" bietet alle "heavy weight" Widgets des JDK 1.1 und unterstützt multiple Frames, Windows and Dialoge, wobei sich einzelne Windows gegenseitig überdecken können.
Mobile Information Device Profile
Wie stark das gesamte Umfeld in jeder Ebene in Bewegung ist, zeigt das Beispiel MIDP. Das "Mobile Information Device Profile" (MIDP) setzt auf dem CLDC auf. Die derzeitige Version 1.0.3 bietet neben einem einfachen Display-Toolkit ein "Persistant Storage"-Paket sowie die Netzanbindung per HTTP 1-Protokoll. Der nächste Schritt der MIDP-Spezifikation (MIDP-NG oder MIDP 2.0) erweitert das bisherige Konzept, um Funktionen im Bereich der Applikations-Distribution (Signaling der Installation, des Löschvorganges, Push-Transfers), der Oberfläche, verbessertem Spiele- und Sound-Support, erweiterten Netzwerkfunktionen (Sockets, HTTPS, serial) sowie einem zusätzlichen Sicherheitsmodell mittels der neuen "Trusted MIDlets", die auf abgesicherte APIs zugreifen können, sofern der Anwender dies für eine so genannte "Protection Domain" explizit gestattet (einmalig, immer, Session).
Das derzeitige Diskussionspapier schließt unter anderem auch einen leichtgewichtigen XML-Parser ein. MIDP 2.0 soll in der zweiten Jahreshälfte als Implementation diverser Hersteller vorliegen. Auch die CLDC-Basis will man modernisieren. Neben der Einführung des Gleitkomma-Supports sollen die Fehlerbehandlung, der Class-Loader und der Sicherheitsmanager verbessert werden. Kombiniert mit den Neuerungen, die durch die einzelnen Profiles Einzug halten werden, müssen Applikationsentwickler in den nächsten Monaten bei ihrer Abkehr vom bisherigen PersonalJava eine Vielzahl neuer Funktionen erlernen und deren Einsatz testen. Entsprechende Applikationen sind also erst zum Jahresende oder später zu erwarten.
Seitenarm Monty
Mit der eigenständigen und von Grund auf neu entwickelten 32-Bit-VM des "Project Monty" hat man bei Sun noch eine zweite VM-Technologie im Köcher, die in diesem Sommer zuerst in Symbian 7-0-Systemen auf ARM- und später auch anderen Plattformen zum Einsatz kommen soll. Im Vergleich zur alten KVM für den StrongARM soll die Performance um den Faktor zehn und auf x86-Systemen um den Faktor sieben steigen. Möglich ist dies durch dynamische Kompilierung, wobei man mit einem integrierten Code-Cache sowie einer veränderten Synchronisation Ideen von Hotspot "ausgeliehen" hat, diversen Tricks zur Verminderung der Speicherfragmentierung sowie unter anderem einer optimierten Garbage Collection (GC), die nicht immer alle Objekte "aufräumt".
Die Monty-VM arbeitet mit einem simplen, dafür aber schnellen Interpreter und kombiniert dies mit dem Hotspot-Kompilat. Zwar steigt dadurch der Speicherbedarf an, doch sei der Performance-Zuwachs noch wichtiger. Monty soll kombiniert mit CLDC, MIDP und kleinen Applikationen einen Speicherbedarf von knapp einem MByte haben.
Fazit
Die JavaOne hat gezeigt, dass Java für die Zukunft des Internet gerüstet ist. Besonders hinsichtlich der vielen und vielfältigen mobilen Geräte. Dort macht eine einheitliche und mit den Fähigkeiten des Geräts skalierbare Umgebung wie Java nicht nur Sinn, sie ist sogar notwendige Voraussetzung für den Erfolg des mobilen Internets.
Auch bei den Webservices hat Java gegenüber Microsofts .Net einige Vorteile. Diese liegen allerdings mehr in der Psychologie begründet: Die zu enge Bindung an Microsoft macht nicht wenigen Internet-Anbietern Angst, wie der Eklat um Hailstorm zeigte. Sun und Java scheinen da für manche die bessere Alternative zu sein. (Jürgen Fey/mha)
Java für verschiedene Devices im Überblick
Technologie | Speicher-bedarf (für Java) | Footprint | Oberfläche | Netzwerk | Bemerkung |
|---|---|---|---|---|---|
| |||||
CLDC | 160/512 KB | Kleinste Displays, einfachstes UI | Limitiert | Kleine Geräte mit Batteriebetrieb. Applikationen als MIDlets. | |
CDC | 2 MByte Flash, 512 KByte RAM | 1011 KByte | Volle Connectivity | Eingeschränkte APIs als J2SE 1.3-Subset. Zusätzliche Dateizugriffe und Datagram-Support. | |
MIDP, Mobile Information Device Profile | Display Toolkit | HTTP 1 über TCP/IP oder anderes Protokoll (WSP, TL/PDC-P) | Persistent Data, http 1.1 | ||
Foundation Profile API | 553 KByte | Keine | Komplettiert die eingeschränkten APIs CDC | ||
CVM | 258 KByte Static, 124 KByte Natives, 28 KByte Porting Layer, Gesamt: 410 KByte | ROMable VM mit kleinem Footprint |
Links zur JavaOne
Paket | Beschreibung | |
|---|---|---|
| ||
Source-Version des CDC für vxWorks und Linux | ||
Weiter führende Literatur | ||
JSR 118 | ||
Session-Papers zu Monty | ||
J2ME-Archive | ||
Java Community Process | ||
Informationen zu Java und Spielen | ||
Informationen zu Java und Wireless | ||
JSR zu Personal Profile | ||
JSR zu PDA-Profile |