7 The nice thing about standards is that you have so many to choose from; furthermore, if you don t like any of them, you can just wait for next year s model. Andrew S. Tanenbaum Die Java Micro Edition ist die»kleinste«der drei Java-Editionen und das in mehrerlei Hinsicht. Zum einen ist sie für den Einsatz in kleinen Endgeräten ausgelegt, die erheblich weniger Rechenleistung und Speicherkapazität aufbieten können als die Desktop- und Serversysteme, auf denen die JavaSE und JavaEE zum Einsatz kommen. Als Folge dieser Ressourcenbeschränkung fällt zum anderen der Funktionsumfang, gemessen an der Zahl der Programmierschnittstellen in den Klassenbibliotheken, bei der Micro Edition zwangsläufig bescheidener aus als bei den mächtigeren Editionen. Ferner ist der Leistungsumfang der Java Virtual Machine eingeschränkt, was sich etwa im Fehlen eines Just-in-Time-Compilers niederschlagen kann. Zu guter Letzt unterstützt die virtuelle Maschine nicht notwendigerweise den vollständigen Java-Sprachumfang, so wie er aus der Standard Edition bekannt ist. Trotzdem wirkt die JavaME häufig als die am schwierigsten zu durchschauende Edition. Das kann zum Teil daran liegen, dass sich die zumeist vorhandenen Erfahrungen aus JavaSE-Projekten nicht unverändert auf JavaME-basierte Entwicklungen übertragen lassen. Denn mitunter existieren für eine bestimmte Aufgabe, etwa Netzwerkprogrammierung oder die Gestaltung von Bedienoberflächen, um nur zwei Beispiele zu nennen, in der JavaSE und JavaME unterschiedliche Philosophien und Programmierschnittstellen. Zum größeren Teil resultieren die Einstiegshürden aber wohl aus dem Fehlen einer einheitlichen, durchgängigen Spezifikation und einer umfassenden Referenzimplementierung. Vielmehr gibt es mehrere, teilweise aufeinander aufbauende, sich teilweise überlappende und sich zum anderen Teil gegenseitig ausschließende Spezifikationen, die in der Summe unter dem Begriff»JavaME«firmieren. Referenzimplementierungen sind dementsprechend auch nur für einzelne Spezifikationen oder Gruppen von verwandten Spezifikationen erhältlich.
8 2.1 Konfigurationen, Profile und optionale Pakete JVM und KVM Zwei Säulen Java Specification Request Um einen ersten Überblick über die Rolle der diversen Konfigurationen, Profile und optionalen Pakete innerhalb des JavaME-Rahmenwerks zu geben und ihre wechselseitigen Abhängigkeiten aufzuzeigen, ist eine grafische Darstellung wie in Abbildung 2 1 recht hilfreich. Sie reflektiert die in Abschnitt 1.2.3 angerissene Dreischichtenarchitektur. Die Konfiguration in der unteren Schicht stellt eine Klassenbibliothek und eine virtuelle Maschine eine vollständige Java Virtual Machine (JVM) bei der CDC und eine abgespeckte Kilobyte Virtual Machine (KVM) bei der CLDC für die darüber angesiedelten Profile und optionalen Pakete zur Verfügung. Der Funktionsumfang der Konfiguration spiegelt die Leistungsfähigkeit einer Klasse von Endgeräten wider: Die CLDC ist für stark ressourcenbeschränkte Ablaufumgebungen ausgelegt, die CDC benötigt schon eine etwas mächtigere Grundlage. Die Profile und (in manchen Fällen) die optionalen Pakete sind an eine bestimmte Konfiguration gebunden. Das Foundation Profile setzt beispielsweise bestimmte Klassen und Leistungsmerkmale in der virtuellen Maschine voraus, die bei der CLDC nicht vorhanden sind. Wegen dieser Abhängigkeiten haben sich innerhalb der JavaME de facto zwei getrennte Säulen herausgebildet. Die Spezifikationen der einzelnen Konfigurationen, Profile und optionalen Pakete gehen aus verschiedenen JCP-Gruppen hervor. Startpunkt der Aktivitäten einer Gruppe ist ein so genannter Java Specification Request (JSR), das Resultat ist eine Spezifikation, eine dazu korrespondierende Referenzimplementierung und ein Technology Compatibility Kit (TCK), mit dem die Kompatibilität einer Implemen- Abb. 2 1 Editionen, Konfigurationen, Profile und optionale Pakete Java Enterprise Edition (JavaEE) RMI Java Micro Edition (JavaME) Optionale Pakete WMA MMAPI PDA BT Web Svc. Location....... Personal Java Standard Edition (JavaSE) Personal Basis Foundation Profile CDC MIDP IMP CLDC Profile JVM JVM KVM
2.1 Konfigurationen, Profile und optionale Pakete 9 tierung mit der Spezifikation überprüft werden kann. Die Ergebnisse sind unter der Adresse http://www.jcp.org/en/jsr/all/ verfügbar. Diese Seite ist jedoch nicht auf die JavaME spezialisiert, sondern beinhaltet auch Arbeiten aus dem JavaSE- und JavaEE-Umfeld. Ist die Gruppennummer bekannt, so ist mit einer speziellen URL ein direkter Zugriff möglich, z. B. http://www.jcp.org/en/jsr/detail?id=139 für JSR-139. Für die Konfigurationen zeichnen vier Expertengruppen verantwortlich, die in Tabelle 2 1 zusammengestellt sind. JSR Gegenstand Ver. 30 Connected, Limited Device Configuration (CLDC) 1.0 139 Connected, Limited Device Configuration (CLDC) 1.1 36 Connected Device Configuration (CDC) 1.0 218 Connected Device Configuration (CDC) 1.1 Tab. 2 1 Konfigurationen für die JavaME Die Profile sind in Tabelle 2 2 aufgelistet. Oberhalb der CLDC gibt es neben dem MIDP, auf das im weiteren Verlauf des Buchs in aller Ausführlichkeit eingegangen wird, mit dem Information Module Profile (IMP) noch ein weiteres Profil. Auf der Seite der CDC existieren drei Profile mit einer»zwiebelartigen«struktur: Das Personal Profile enthält das Personal Basis Profile, das seinerseits das Foundation Profile umschließt. Prinzipiell ist jedoch auch eine Implementierung von MIDP oberhalb der CDC anstelle der CLDC denkbar. JSR Gegenstand Ver. CLDC CDC 37 Mobile Information Device Profile (MIDP) 1.0 118 Mobile Information Device Profile (MIDP) 2.0 ( ) 195 Information Module Profile (IMP) 1.0 228 IMP Next Generation (IMP NG) 1.0 46 Foundation Profile 1.0 219 Foundation Profile 1.1 129 Personal Basis Profile 1.0 217 Personal Basis Profile 1.1 62 Personal Profile 1.0 216 Personal Profile 1.1 Tab. 2 2 Profile für die JavaME Das Einsatzgebiet des IMP sind Module, die im Bereich Machine-to- Machine-Kommunikation eine bedeutende Rolle spielen. Bezogen auf Datendienste verfügen diese Module über ähnliche Fähigkeiten wie Machine-to-Machine: IMP
10 Profile für die CDC CLDC für Mobiltelefone Optionale Pakete Mobiltelefone, haben aber keine Bedienoberfläche im gewohnten Sinne und unterstützen keine Sprachtelefonie. Meist finden sich IMP- Module als Komponenten in anderen Produkten und Lösungen wie Automaten oder Ortungseinheiten. Mit dem IMP könnte beispielsweise ein Getränkeautomat selbstständig Nachschub anfordern, sobald ein bestimmter Restbestand an Mineralwasser unterschritten wird. Eine Ortungseinheit mit integriertem GPS-Empfänger könnte auf einen bestimmten Reiz hin (Lichteinfall, Erschütterung, Temperatur usw.) ihre aktuelle Position an einen Server melden. Die Klassenbibliotheken des IMP sind jeweils echte Teilmengen der entsprechenden MIDP-Version: IMP 1.0 ist eine Teilmenge des MIDP 1.0, IMP NG des MIDP 2.0. Für die CDC 1.0 und die darauf aufbauenden Profile, nämlich das Foundation Profile 1.0, das Personal Basis Profile 1.0 und das Personal Profile 1.0, stand die Java Standard Edition Version 1.3 Pate. Die CDC 1.1 und die entsprechenden Profile mit der Versionsnummer 1.1 orientieren sich an der JavaSE 1.4.2. Die CDC und die drei genannten Profile definieren sich durchweg als mehr oder weniger umfangreiche Teilmengen der Klassenbibliothek der Standard Edition. Das Foundation Profile ist die kleinste dieser Teilmengen, die unter anderem auf den Bereich der grafischen Bedienoberfläche in Gänze verzichtet. Das Personal Basis Profile übernimmt einen Teil der Pakete des Abstract Window Toolkits (AWT), lässt dabei aber Klassen für schwergewichtige Komponenten wie java.awt.button oder java.awt.list weg. Letztere sind schließlich im Personal Profile enthalten. In den derzeit erhältlichen Mobiltelefonen ist die CDC indes noch nicht sehr verbreitet. Dank der ständig zunehmenden Leistungsfähigkeit der Hardware wird in neu erscheinenden Geräten zwar zunehmend ein Trend hin zur CDC zu beobachten sein; für den Anwendungsentwickler bieten heutzutage aber die CLDC und das MIDP eine Plattform mit einer weitaus größeren Marktdurchdringung. Aus kommerzieller Sicht ist dabei vor allem die millionenfache Verbreitung von Mobiltelefonen, die die CLDC und das MIDP unterstützen, und das noch zu erwartende Wachstum interessant. Aus technischer Warte erscheint die künftige Weiterentwicklung der Plattform gesichert. Die diversen optionalen Pakete, die bereits existieren oder sich derzeit in Vorbereitung befinden, untermauern diese Prognose. Einige dieser optionalen Pakete sind in Tabelle 2 3 zusammengestellt. Die Verfügbarkeit der optionalen Pakete in den Endgeräten kann von Hersteller zu Hersteller, und innerhalb des Portfolios eines Herstellers von Modell zu Modell variieren. Die Portabilität von Applikationen, die von optionalen Paketen Gebrauch machen, ist deshalb in
2.1 Konfigurationen, Profile und optionale Pakete 11 JSR Gegenstand Ver. 75 PDA Optional Packages 1.0 82 Java APIs for Bluetooth 1.0 120 Wireless Messaging API (WMA) 1.1 135 Mobile Media API (MMAPI) 1.1 172 Web Services API 1.0 177 Security and Trust Services API (SATSA) 1.0 179 Location API 1.0 180 SIP API 1.0 205 Wireless Messaging API (WMA) 2.0 211 Content Handler API (CHAPI) 1.0 226 Scalable 2D Vector Graphics API 1.0 229 Payment API (PAPI) 1.0 234 Advanced Multimedia Supplements (AMMS) 1.0 238 Mobile Internationalization API 1.0 253 Mobile Telephony API (MTA) 1.0 Tab. 2 3 Optionale Pakete für die CLDC der Praxis eingeschränkt. Ausführlichere Informationen zu den optionalen Paketen finden sich in Kapitel 11. Eine weitere, auf JSR-185 zurückgehende Spezifikation, Java Technology for the Wireless Industry (JTWI), ist ein Versuch, eine gemeinsame Basis für Applikationen zu legen, deren Ansprüche die Leistungsmerkmale der Konfiguration und des Profils übersteigen. JTWI stellt eine Art Gütesiegel dar: Ein JTWI-kompatibles Gerät implementiert mindestens den in JSR-185 festgelegten Funktionsumfang und muss dies in einer umfangreichen Test-Suite nachgewiesen haben. Wie in der JTWI-Referenzarchitektur in Abbildung 2 2 zum Ausdruck kommt, werden neben der CLDC 1.0 oder 1.1 und dem MIDP 2.0 das Wireless Messaging API und (Teile des) Mobile Media API gefordert. Diese beiden Pakete betreffen Grundfunktionalität, die heute jedes gängige Mobiltelefon beherrscht. Daher liegt der Wunsch, diese Funktionen auch in Java nutzen zu können, auf der Hand. Zusätzliche optionale Pakete und proprietäre Java-Klassenbibliotheken dürfen ebenfalls vorhanden sein. Darüber hinaus bringt JSR-185 einige Konkretisierungen für Aspekte, bei denen die CLDC- und MIDP-Spezifikationen noch Interpretationsspielraum lassen. Während die CLDC beispielsweise nur definiert, dass die Systemuhr über System.currentTimeMillis() ausgelesen werden kann, macht JTWI Vorgaben für die Taktrate der Uhr. Java Technology for the Wireless Industry
12 Abb. 2 2 Referenzarchitektur nach JSR-185, Java Technology for the Wireless Industry MIDP 2.0 (JSR-118) MIDlet-Suites, OEM-Anwendungen WMA 1.1 (JSR-120) MMAPI 1.1 (*) (JSR-135) Optionale Pakete OEM- Klassen Nativer Browser Natives AMS / OTA Native Anwendungen CLDC 1.0 (JSR-30) / CLDC 1.1 (JSR-139) Betriebssystem Hardware (*) Teilmenge 2.2 Anforderungen an die Hardware In Bezug auf ihre Rechenleistung liegen mobile Endgeräte heute in einer ähnlichen Größenordnung wie Heimcomputer vor weniger als 20 Jahren. Die Mindestaustattung für ein JavaME-konformes Gerät ist in den Spezifikationen recht detailliert festgehalten, wobei es den einzelnen Herstellern natürlich überlassen bleibt, mehr zu bieten. Im Wesentlichen richten sich die Anforderungen an: die Speicherkapazität das Display die Eingabemöglichkeiten die Netzwerkanbindung die Multimedia-Fähigkeiten Die für die CLDC, die darauf aufbauenden Profile MIDP und IMP sowie JTWI vorgeschriebenen Werte sind in Tabelle 2 4 zusammengestellt. Die Tabelle differenziert zwischen drei Speicherarten mit unterschiedlichen Aufgaben: Im ROM sind Klassenbibliotheken und bei der CLDC auch die virtuelle Maschine implementiert. Das RAM entspricht dem Arbeitsspeicher, der den Applikationen zur Verfügung steht. Der persistente Speicher ist für Anwendungsdaten vorgesehen, die dauerhaft gespeichert werden müssen. Die Speicheranforderungen der Profile sind additiv zu denen der Konfiguration. So benötigt beispielsweise ein Endgerät, in dem die CLDC 1.0 und das MIDP 2.0 realisiert sind, einen RAM-Speicher mit einer Kapazität von 160 kb: 32 kb für die CLDC plus 128 kb für das