Ausarbeitung - Department of Information Systems
Werbung
Westfälische Wilhelms-Universität Münster Ausarbeitung JavaME Konfigurationen (im Rahmen des Seminars "Mobile Java") Yifan Tan Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Michael Poldner Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft Inhaltsverzeichnis 1 Einleitung................................................................................................................... 3 2 Konfigurationen in Java ME...................................................................................... 4 2.1 2.1.1 2.1.2 2.1.3 2.1.4 2.2 2.2.1 2.2.2 2.2.3 2.2.4 3 CLDC 1.1.......................................................................................................... 5 Grundkonzept................................................................................................ 5 Eigenschaften................................................................................................ 7 Klassenbibliotheken.................................................................................... 10 Neuerung der CLDC 1.1 im Vergleich zu 1.0 ............................................ 15 CDC ................................................................................................................ 16 Anforderungen an die Hardware................................................................. 16 Aufbau und Eigenschaften.......................................................................... 16 Sicherheitssystem........................................................................................ 17 Einschränkungen und Erweiterungen im Vergleich zur J2SE.................... 18 Zusammenfassung ................................................................................................... 19 Literaturverzeichnis ........................................................................................................ 20 1 Einleitung „Bis Ende 2006 werden weltweit 986 Millionen Mobiltelefone verkauft werden. Die Zahl der verkauften Geräte dürfte 2007 weltweit bei 1,1 Milliarden liegen.“ Das ist das Ergebnis einer am 22.11.2006 veröffentlichten Studie der Marktforschungsfirma Gartner [Ga06]. Jetzt gibt es kaum noch Menschen, die nicht über mindestens ein Mobiltelefon erreichbar sind. Ein Mobiltelefon von heute bietet viel mehr als nur die Möglichkeit zu telefonieren, z.B. die Möglichkeit MMS Nachrichten zu versenden, Klingeltöne zu ändern, eine Kamerafunktion, eingebaute Spiele usw. Außerdem bietet es die Möglichkeit, spezielle Anwendungen aus dem Internet auf das Handy zu laden. Die Java Micro Edition (J2ME) ist die jüngste, auch kleinste Generation der Java 2 Plattform Familie. Das Anwendungsgebiet der J2ME liegt im Bereich der mobilen Applikationen und der Möglichkeit, Java Applikationen auch mit beschränkten Ressourcen zu nutzen. Die Konfiguration ist eines der wichtigsten technischen Konzepte, auf denen die J2ME beruht. Diese Arbeit soll die Connected Limited Device Configuration und Connected Device Configuration vorstellen und deren Begrenzungen und Erweiterungen zur Java 2 Standard Edition (J2SE) diskutieren. Fragen wie: Wozu werden Konfigurationen in Rahmen der J2ME benötigt? Welche Rahmenbedingen werden von Konfigurationen geregelt? Welche grundlegenden Unterschiede lassen sich bei den Konfigurationen in J2ME gegenüber der anderen Java Edition erkennen? werden schrittweise im Verlauf dieser Arbeit beantwortet. Nach der Einleitung wird zunächst auf die theoretischen Grundlagen zu den Konfigurationen in J2ME eingegangen. Dabei werden zwei verschiedene Konfigurationen vorgestellt. Im Kapitel 2.1 und 2.2 wird eine Detailanalyse über die Anforderungen und Aufgaben, den Aufbau und die Eigenschaften der jeweiligen Konfiguration gebildet. Weiterhin werden Klassenbibliotheken beschrieben und ausführlich auf die spezifischen Klassen der Konfigurationen eingegangen. In diesem Zusammenhang wird auch ein Vergleich zur J2SE vorgestellt, der sich nach Einschränkungen aufgliedert. Die gewonnen Erkenntnisse werden im abschließenden Teil der Arbeit zusammengefasst. -3- 2 Konfigurationen in Java ME Die Zahl der auf dem Markt verfügbaren Geräte, wie Handys und PDAs, steigt ständig an. Jedes Endgerät hat eigene Eigenschaften. Die Java Laufzeitumgebung muss auf diese Eigenschaften abgestimmt sein. Neben vielen Unterschieden gibt es aber auch Gemeinsamkeiten, z.B. bei Prozessoren und Speichergröße. Deshalb ist es sinnvoll, gleichartige Geräte zusammenzufassen und jeder Gruppe eine speziell angepasste Version der J2ME zur Verfügung zu stellen. Konfigurationen definieren eine horizontale Gruppierung der Produkte, die auf der gleichen Größe des Hauptspeichers und Leistung des Prozessors basieren. Anhand dieser Basis an unterstützten Hardwaremerkmalen werden von der Konfiguration folgende Angaben definiert [RTP04]: • Die Unterstützung von Merkmalen und Eigenschaften der Java-Programmiersprache • Die Unterstützung von Merkmalen und Features der Java Virtuelle Maschine • Die unterstützten Java - Application Programming Interfaces (APIs). Konfigurationen sind Spezifikationen innerhalb der J2ME Architektur, die von einer Expertengruppe definiert werden, die den Java Community Prozess (JCP) verwendet. Zurzeit gibt es zwei J2ME Konfigurationen: • Connected Limited Device Configuration (CLDC) • Connected Device Configuration (CDC) Die CLDC konzentriert sich auf persönliche Endgräte mit beschränkter Speicherausstattung, schwacher Rechenleistungen [KH03], einer geringen Bandbreite und oftmals instabilen Netzwerkverbindungen, wie z.B. bei Mobiltelefonen. Die CDC ist geeignet für die Endgeräte mit größerer Speicherausstattung, dauerhaften Netzwerkverbindungen und vielfältigen Benutzerschnittstellen, wie z.B. bei Autonavigationssystemen. Abbildung 1 veranschaulicht das Verhältnis zwischen Konfigurationen und virtuellen Maschinen und zeigt die unterschiedlichen Anwendungsbereiche von CLDC und CDC. Konfigurationen legen den Zusammenhang zwischen einem Profil und der Java virtuellen Maschine fest. Profile stellen Geräte und User-spezifische APIs zur Verfügung. -4- Abbildung 2: Anwendungsbereiche von CLDC und CDC Wie in dieser Abbildung in Anlehnung an [RTP04] dargestellt, haben die CDC und die CLDC Konfigurationen ihre eigenen virtuellen Maschinen. Die CDC benutzt die Connected-Virtuelle Maschine (CVM) und die CLDC verwendet die Kilobyte-virtuelle Maschine (KVM) [To02]. Die Implementierung einer J2ME virtuellen Maschine muss die Spezifikationen beachten, die durch die Konfiguration definiert werden. Besonders im KVM wird Funktionalität explizit entfernt, um der geringen Speicheranforderung der CLDC zu genügen [GDC02]. 2.1 CLDC 1.1 2.1.1 Grundkonzept 2.1.1.1 Zielsetzungen Einer der wichtigsten Gründe für die Entwicklung der J2ME ist die Festlegung des Standards einer Java-Plattform für kleine, vernetzte Geräte mit eingeschränkten Ressourcen. Dies ist die Aufgabe der CLDC, die damit die Anforderung erfüllt, dynamische Java-Anwendungen auf Geräten wie zum Beispiel Handys oder Organizern auszuführen. Das Primärziel dieser Konfiguration ist, dass die CLDC Spezifikation einen „kleinsten gemeinsamen Nenner“ [Ma02] definiert, der nur die minimalen Java -5- Plattform-Eigenschaften und die APIs für eine große Anzahl unterschiedlicher Endgeräte bereitstellt. Ein weiteres Ziel der CLDC ist es, die Java-Plattform nicht nur aufgrund der eingeschränkten Ressourcen zu minimalisieren, sondern gleichzeitig einen mächtigen Befehlssatz für die möglichst einfache Entwicklung mobiler Anwendungen bereitzustellen. Die CLDC garantiert dem Programmierer, dass seine Software auf allen Geräten lauffähig ist, welche die CLDC-Klassen bereit stellen. Vorteile für den Programmier bzw. Entwicklers und auch für der Gerätehersteller werden durch die CLDC-Referenzimplementierung (RI) realisiert. Sie ist in erster Linie für HandwareIndustrie von Interesse, die die CLDC auf eine neue Handware portieren und nativen Code einbinden möchten. 2.1.1.2 Anforderungen an die Handware und Software Die CLDC schränkt nicht die Hardware-ausstattung ein, weil sich sehr unterschiedliche Geräte anbieten, um Java zu nutzen. Die einzige Beschränkung bezieht sich auf die Speichergröße, die das Gerät bereitstellen muss. Die Mindestanforderungen der CLDC an die Hardware sind folgende [BM06]: • Es müssen mindestens 32 Kilobyte flüchtiger Speicher (RAM) für die Laufzeitumgebung von Java (JVM) vorhanden sein. • Es müssen mindestens 160 Kilobyte nichtflüchtiger Speicher (ROM) für die JavaUmgebung vorhanden sein. Diese werden von der Virtuelle Maschine (KVM) und den CLDC Bibliotheken in Anspruch genommen. • Die Verbindung zu einem Netzwerk muss vorhanden sein. Hierbei kann die Verbindung wahlweise drahtlos erfolgen. Die Bandbreite darf zudem unter 9600 Baud liegen. • Das Endgerät darf über eine mobile Stromversorgung verfügen. Die Anforderungen an das Betriebssystem des verwendeten Endgerätes sind relativ gering und definieren nur die Mindestvoraussetzung. Die einzige Grundvoraussetzung für die Software ist ein minimales „host operating system“, falls nicht der Kernel selbst die zu Grunde liegende Hardware verwalten kann. Das „host operating system“ muss weder getrennte Adressräume oder Prozesse verwalten können, noch braucht es eine Echtzeitunterstützung. Es muss nur die Ablaufsteuerung eines einzelnen Prozesses überwacht werden, um die Java Virtuelle Maschine ausführen zu können. -6- 2.1.1.3 Anwendungsgebiete und -abgrenzungen Um den geringen Speicher nicht zu übersteigen, hat die CLDC Expertengruppe entschieden, den Anwendungsbereich von CLDC möglichst eng einzuschränken. Basierend auf den Entscheidungen der Expertengruppen JSR-30 und JSR-139 [BM06], deckt CLDC Spezifikation die folgenden Anwendungsgebiete ab: • Festlegung der Merkmale der Java Sprache und der Virtuelle Machine • Bestimmung des Kerns der Java Bibliotheken [java.lang.*, java.util.*] • Input und Output auf dem Endgerät (java.io.*) • Sicherheit • Netzverbindungen • Internationalisierung Folgende Aufgaben gehören nicht zu dem Anwendungsgebiet der CLDC Spezifikation, sondern werden von den jeweiligen Profilen umgesetzt: • Installation, Ausführung und Entfernen von Anwendungen • Benutzerschnittstelle • Ereignisbehandlung 2.1.2 Eigenschaften 2.1.2.1 CLDC Application Model Der Aufbau einer J2ME-Implementierung in einem Mobiltelefon wird in Abbildung 2 veranschaulicht. Er besteht aus einer virtuellen Maschine, einer Konfiguration und einem oder mehreren Profilen. Die Implementierung einer CLDC umfasst eine virtuelle Maschine (KVM), welche der Java VM Spezifikation und der Java-Sprachspezifikation entspricht. Die virtuelle Maschine ist ein Bestandteil, der logisch über dem Host Betriebssystem sitzt. Über der virtuellen Maschine sind die Java Bibliotheken hinterlegt. Einige dieser Bibliotheken werden durch die CLDC selbst definiert. Zusätzliche Bibliotheken und Eigenschaften können durch J2ME Profile definiert werden, welche auf CLDC bzw. CDC basieren. -7- J2ME Application Mobile Information Device Profil PDAP PDA Profil CLDC (Connected Limited Device Configuration) Klassebibliothek CLDC Profiles MIDP K Virtuelle Maschine Betriebssystem (PalmOS, Windows32, Linux oder Solaris) Abbildung 2: Aufbau der CLDC Application Modell Auf dem Markt stellen einige mobile Endgräte eine graphische Benutzschnittstelle zur Verfügung, während andere nur eine Text-Benutzerschnittstelle bieten können bzw. keine sichtbare Benutzerschnittstelle haben. Die CLDC kann keiner spezifischen Kategorie der Endgräte zugeordnet werden. Aus diesem Grund ist das Anwendungsmodell, das in der CLDC Spezifikation definiert wird, relativ einfach. Die CLDC umfasst eine Sammlung von class-files, auf welche sich die Anwendungen stützen. Sie enthalten die Methode main, die als eine Startmethode für jedes Java Application ist. Die Methode main wird wie folgt deklariert: public static void main (String [] args). Durch den Aufruf von main startet die KVM eine Java Application. J2ME Profile, wie das Mobile Information Device Profile (MIDP), können alternative Anwendungsmodelle definieren, die das grundlegende Anwendungsmodell von CLDC definiert oder erweitet. Das Management der Anwendungen bezieht sich auf die folgenden Fähigkeiten: • Download und installation einer Java Application • Kontrolle der bestehenden Java Application, die auf den Endgeräten gespeichert werden • Auswahl und Durchführung der Java Application -8- • Löschen einer bestehenden Java Application Das CLDC System kann mehrere Java Applications gleichzeitig ausführen lassen oder das System beschränken, um nur die Durchführung von einer Java Application zu ermöglichen. Dieses ist abhängig von den zur Verfügung gestellten Ressourcen auf dem Endgerät. Die gleichzeitige Ausführung mehrerer Java Applicationen wird entweder von der Multitaskingfähigkeit auf dem Host Betriebssystem oder von mehreren logischen virtuellen Maschinen unterstützt. An dieser Stelle entscheidet die CLDC sich für eine optimale Lösung. 2.1.2.2 Sicherheit Die Sicherheit spielt im Bereich mobiler Anwendungen und kabelloser Netze eine besonders wichtige Rolle. Die J2SE ist so aufgebaut, dass sie den Entwicklern eine Reihe umfangreicher und flexibler Schutzmechanismen bietet. Die Gesamtmenge des Codes für Sicherheit in der J2SE ist größer als der Gesamtspeicher, der für die CLDC vorhanden ist. Daher ist das Sicherheitsmodell der CLDC im Vergleich deutlich eingeschränkt [Es03]. Das Sicherheitsmodell der CLDC wird auf zwei unterschiedlichen Ebenen definiert: Das Sicherheitssystem auf low-level Ebene Es wurde eine Pre-verifikation entwickelt, die nur wenige Systemressourcen benötigt. Der gesamte Verifikationsprozess wird in zwei Teile unterteilt. Die eigentliche Klassenverifikation wird auf dem Desktop-Rechner des Entwicklers durchgeführt. Nach der Überprüfung werden die korrekten Dateien mit dem Attribut „StackMap“ markiert. Zur Laufzeit auf dem mobilen Endgerät wird nur das Attribut „StackMap“ überprüft, nicht aber die kompletten class-Dateien. Diese Überprüfung benötigt nur wenige Systemressourcen. Das Sicherheitssystem auf der Anwendungsebene Durch die Sicherheitsmaßnahmen auf der untersten Ebene können nicht alle Sicherheitslücken geschlossen werden. Dort wird nur die Gültigkeit der JavaAnwendung überprüft, was aber hat keinen Einfluss auf die von den Anwendungen durchgeführten Aktionen hat. Das Sicherheitssystem auf der Anwendungsebene sorgt -9- dafür, dass nur auf die freigegebenen Klassenbibliotheken und Systemressourcen zugegriffen wird. Dies wird gewährleistet durch die folgenden Mechanismen: - Das Prinzip des Sandbox-Modells: In diesem Modell wird eine feste Laufzeitumgebung zur Verfügung gestellt, innerhalb der die Applikationen eine gesicherte Ablaufumgebung finden. Java-Anwendungen können nur auf Klassenbibliotheken oder Ressourcen zugreifen, die zuvor definiert wurden. - Schutz der Systemklassen: Dieser Mechanismus verhindert, dass neu installierte Anwendungen Systemklassen überschreiben. 2.1.3 Klassenbibliotheken Die CLDC Klassenbibliothek enthält die Interfaces und grundlegenden Klassen, welche in zwei Kategorien eingeteilt werden. Wie in Abbildung 3 dargestellt, besteht die erste aus einer Teilmenge der Java 2 Standard Edition (J2SE) Klassen und die zweite aus CLDC-spezifischen Klassen. Abbildung 3: CLDC Klassebibliothek 2.1.3.1 Geerbte Klassen von J2SE Die Bibliothek der CLDC bietet viele Klassen, die aus J2SE 1.3.1 Bibliotheken übernommen werden. Die Klassen, die mit J2SE Klassen identisch sind oder zu einer Teilmenge der entsprechenden J2SE Klassen gehören, müssen mit dem gleichen Paketnamen definiert werden. Die Semantik dieser Klassen und ihrer Methoden darf nicht geändert bzw. ergänzt werden. In der Tabelle 1 werden die Pakete, Klassen und Interfaces in die CLDC 1.1. eingeordnet und dargestellt. - 10 - JavaPaket Klassetype System Datentypen Fehler Klassen Interfaces Objet, Class, Runtime, Thread, String, StringBuffer, Throwable Boolean, Byte, Short, Integer, Long, Character Float, Double Error, NoClassDefFoundError, OutOfMemoryError, Exception, java.lang. Exception System, Runnable VirtualMachineError ArrayIndexOutOfBoundsException, ArithmeticException, ArrayStoreException, ClassNotFoundException, ClassCastException, IllegalThreadStateException, IllegalAccessException, IllegalMonitorStateException, IllegalArgumentException, IndexOutOfBoundsException, InstantiationException, InterruptedException, NullPointerException, NegativeArraySizeException, NumberFormatException, RuntimeException, SecurityException, StringIndexOutOfBoundsException ergänzend Weak java.lang.ref Reference java.util. Math Reference, WeakReference Collections Vector, Stack, Hanshtable Klander und Zeit Calender, Date, TimeZone Exception ergänzend Input / Output java.io. Exception EmptyStackException, Enumeration NoSuchElementException, Randum InputStream, OutputStream, ByteArrayInputStream, ByteArrayOutputStream, DataInputStream, DataOutputStream, Reader, PrintStream, Writer, InputStreamReader, OutputStreamWriter InterruptedIOException, IOException, DataInput, DataOutput UnsupportedEncodingException, UTFDataFormatException Tabelle 1: Pakets, Klassentype, Klassen und Interfaces in der CLDC 1.1. Diese Tabelle zeigt, dass java.lang, java.util, und java.io jeweils nur eine Teilmenge der J2SE umfassen. Sie bieten auch nicht alle Methoden und Konstanten wie die gleichnamigen Pakete in J2SE [BM06]. - 11 - 2.1.3.2 CLDC spezifische Klassen – Generic Connection framework Die CLDC spezifischen Klassen werden im Paket javax.microedition.io deklariert. Im Bereich des Netzwerk- und Speicherzugriffes unterstützt J2SE viele unterschiedliche Funktionen der Ein- und Ausgabe für den Verbindungsaufbau. Diese Funktionen sind nicht in die CLDC übertragbar, da der Speicherbedarf zu groß wäre. Aus diesem Grund sind in dem Package „javax.microedition.io“ eine Reihe von Verbindungsklassen, die spezielle Netzwerkfunktionen implementieren, allgemein unter dem Namen Generic Connection Framework (GCF) bekannt. Durch diesen Standard ist es möglich, die Verbindungen zu einem Kommunikationspartner einheitlich durch die Connection-Schnittstelle zu realisieren [Sc07]. Der Vorteil des GCF liegt in den gleich bleibenden Schnittstellen. Unabhängig vom Übertragungsprotokoll stellt Connection ein API zur Verfügung, das auf alle Arten von Verbindungen gleichermaßen anwendbar ist. Die Syntax eines „Connector.open“-Aufrufes stellt sich wie folgt dar [RTP04]: Allgemein: Connector.open ("<protocol>:<address>;<parameters>"); HTTP Connection: Connector.open ("http://www.sun.com:port"); Socket Connection: Connector.open ("socket://129.144.111.222:2800"); Communication ports: Connector.open ("comm:0;baudrate=9600"); Datagrams Connection: Connector.open ("datagram://129.144.111.222:2800"); Die Methode Connector.open wird ein Parameter in Form eines Strings übergeben, um bei einem Verbindungsaufbau das richtige Protokoll für die Datenübertragung auszuwählen. Das Klassendiagramm in Abbildung 4 zeigt in Anlehnung an [Sc07] die wesentliche sieben Klassen und Interfaces des GCF in der CLDC. Wenn ein Verbindungsaufbau erfolgreich durchgeführt wurde, gibt die Methode ein Objekt zurück, das eines der untergeordneten Interfaces aufruft. Wie in Abbildung 4 zu sehen ist, sind die Interfaces hierarchisch angeordnet. - 12 - CLDC <exception> Connection NotFound Esception throws Connector <interface> creates Connection <interface> <interface> <interface> <interface> Datagram Connection Input Connection Output Connection Stream ConnectionNotifier creates <interface> Datagram <interface> Stream Connection <interface> Content Connection Abbildung 4: Klassendiagramm für das Generic Connerction Framework in der CLDC 2.1.3.3 Einschränkungen und Erweiterungen im Vergleich zur J2SE Aufgrund der stark eingeschränkten Ressourcen der mobilen Kommunikationsgeräte fehlen den Klassenbibliotheken der CLDC im Vergleich zur J2SE folgende Funktionen [KH03]: - finalize-Methode Zur Reduzierung des Ressourcenverbrauchs bei CLDC-Geräten ist die finalize()Methode nicht bei der Klasse Objekt zu finden. Die finalize()-Methode der J2SEPlattform unterstützt einer Methode, um offene Verbindung zu schließen (z.B. zum Speicher, Grafikkontext oder zu Streams). - 13 - - Fehler und Exceptions Die Fehlerbehandlung bei mobilen Endgeräten ist im Vergleich zu normalen DesktopSystemen deutlich vereinfacht. Wenn ein Fehler auftritt, der in der J2SE aber nicht in der CLDC definiert ist, soll die JVM anhalten oder ein Objekt einer Error Klasse der CLDC auswerfen [BM06]. Dies wird bereits bei den Exceptions deutlich, die im wesentlichen nur sehr eingeschränkt implementiert wurden. Asynchrone Exceptions werden nicht unterstützt. - Class-Loader Der Class-Loader wird von classLoader geerbt und benutzt in der zu implementierenden Methode loadClass() einen selbstgeschriebenen Algorithmus zum dynamischen Laden von Klassen übers Netzwerk oder vom Dateisystem. Aufgrund höherer Sicherheitsrichtlinien der CLDC wurde diese Eingriffsmöglichkeit des Benutzers nicht realisiert. - Thread Die KVM unterstützt nebenläufige Threads, aber keine Thread-Gruppen und DämonThreads. Der Garbage Collector ist eingeschränkt. - „Weak references“ Es gibt keine „Weak references“ in der CLDC - java native interface (JNI) Das JNI ist nicht verfügbar, um den Zugriff auf für das Java Programm nicht verfügbare Funktionalität des Geräts zu unterbinden. - Reflection Die Reflection-Fähigkeiten der CLDC sind sehr beschränkt. Sowohl class.forName()als auch class.newInstance() sind verfügbar, aber es ist nicht möglich, durch Reflection auf Methoden, Variablen order Konstruktoren zuzugreifen. - Preverifier Bytecode–Verifikation mittels Preverifier und Bytecode wurden neu implementiert und erweitet. - 14 - 2.1.4 Neuerung der CLDC 1.1 im Vergleich zu 1.0 Es gibt keine grundlegenden Änderungen in der neuen Spezifikation. Die CLDC Spezifikation Version 1.1 ist hauptsächlich eine Erweiterung. Sie ist voll abwärtskompatibel zur Version 1.0. Die Mindestanforderung an Speicher wurde von 160 auf 192 KB erhöht, um ein paar neue wichtige Funktionsfähigkeiten wie Fließkomma-Arithmetik [Sc07] hinzuzufügen. Im Folgenden sind die neuen Klassen, Ausnahmen und Methoden in CLDC 1.1 aufgeführt: • Die Datentypen Java.lang.Float und Java.lang.Double sowie deren Wrapper Float und Double wurden hinzugefügt. • Um die Fließkomma-Arithmetik zu unterstützen, wurden die Konstanten java.lang.Math.E und java.lang.Math.PI ergänzt. • Die Klassen und java.lang.ref.Reference java.lang.ref.WeakReference wurden für Unterstützung der schwachen Referenzen beigefügt. • Um eine höhere Kompatibilität mit der J2SE aufzuweisen, sind die Klassen Calender, Date und TimeZone neu entworfen worden. • Das Errorhandling wurde überarbeitet; eine neue Exception NoClassDefFoundError wurde hinzugefügt. • Attribute java.lang.Boolean.TRUE und java.lang.Boolean.FALSE und Methoden String.intern(), String.equalsIgnoreCase(), Date.toString(), Random.nextInt(int n) wurden hinzugefügt. • Die Klasse Thread wurde um neue Mehtoden erweitet. Dies sind thread.getName(), thread.interrupt(), thread.(Runnable Target, String name) und thread.(String name). Alle oben aufgelisteten Klassen und Methoden kommen aus der J2SE Bibliothek. Seit dem Jahr 2003 wird die Konfigurationsversion CLDC 1.1 von den meisten Java-fähigen Handys und Smartphones unterstützt. - 15 - 2.2 CDC 2.2.1 Anforderungen an die Hardware Die CDC wurde für Endgeräte entwickelt, die eine bessere technische Ausstattung als die Geräte der CLDC besitzen, wie z.B. eine größere Speicherausstattung, einen schnelleren Prozessor und eine stabilere Netzwerkanbindung. Die CDC hat die folgenden Anforderungen an Hardware und Software: • Das Endgerät muss mindestens einen 32-bit Prozessor besitzen. • Es müssen mindestens 2 MB nichtflüchtiger Speicher (ROM) für die Virtuelle Machine und die CDC Bibliotheken zur Verfügung stehen. • Es müssen mindestens 2 Megabyte flüchtiger Speicher (RAM) für die Laufzeitumgebung von Java bereitgestellt werden. • Die Verbindung zu einem Netzwerk muss vorhanden sein. Hierbei kann die Verbindung wahlweise drahtlos erfolgen. Die Bandbreite darf zudem unter 9600 Baud liegen. 2.2.2 Aufbau und Eigenschaften - 16 - Abbildung 5: Aufbau der CDC Application Modell Die CDC ist sehr modular aufgebaut. Jede Implementation eines CDC-Profils beinhaltet die Realisierung einer Klassenbibliothek und einer Java Virtuellen Maschine. Die CDCProfile sind in mehreren Schichten angeordnet und können vielfältig kombiniert werden. Auf diese Weise lassen sich Funktionalitäten hinzufügen oder entfernen und optimal an die jeweilige Hardwarebasis anpassen [Sc07]. Die unterste Ebene der Profile bildet das Foundation Profile (vgl. Abb.5). Das Foundation Profile besteht aus einigen Java-APIs und einer kompletten J2ME Laufzeitumgebung. Zudem wird die Netzwerkfunktionalität unterstützt. Das Personal Basis Profil und das Personal Profil liegen auf nachfolgenden Profilschichten. Sie bieten eine grafische Benutzerschnittstelle an. 2.2.3 Sicherheitssystem In der Spezifikation der CDC werden fünf Sicherheitsebenen definiert, die sowohl dem Benutzer als auch dem Anwendungsentwickler eine große Auswahl von Sicherheitsmechanismen zur Unterstützung anbieten [Sc07]: - Virtual Machine Security Die Sicherheitsebene der Virtuellen Maschine ist die unterste Schutzebene. Im Gegensatz zur CLDC übernimmt diese Schutzebene die Klassenverifikation von der J2SE-Spezifikation. Aufgrund zu hoher Sicherheitsrisiken wurden Pointer vermieden. - Signed Classes Signed Classes bieten eine Verbesserung des Sandbox-Modells aus der CLDC. Sie garantieren die Vollständigkeit und Korrektheit der Java Klassendatei, die anschließend von der Virtuellen Maschine geladen wird. - Policy-based security Basierend auf Richtlinien bietet dieses Sicherheitssystem eine Kontrollfunktion an. Mit dieser Kontrollfunktion kann der Zugriff auf Daten, Schnittstellen oder Anwendung festgelegt werden. Diese Richtlinien werden von dem Softwareentwickler festgelegt und können nur von dem Systemadministrator angepasst werden. - Cryptography - 17 - Bei dem Java Sicherheitssystem ist die Verschlüsselung durch die Java Cryptography Architecure (JCA) realisiert. Es bietet die Möglichkeit, Software und Daten für eine sichere Übertragung zu verschlüsseln. - Certificate management Bei diesem standardisierten Mechanismus findet ein Authentifizierungsprozess statt, der durch ein Zertifikat einer Person den Zugriff gewährt. 2.2.4 Einschränkungen und Erweiterungen im Vergleich zur J2SE Die CDC-Geräte haben bessere Hardwareressourcen, so dass die Virtuelle Maschine der J2SE im Prinzip nicht eingeschränkt werden müsste, sondern die komplette Spezifikation unterstützen werden kann. Im Gegensatz zu der CLDC hat die CDC jedoch zusätzliche benutzerspezifische class-Loader, eine vollständige Fehlerbehandlung und die Unterstützung von Fließkommazahlen. Auch die KlassenBibliotheken der CDC weichen nicht so stark von dem J2SE-Standard ab, wie bei der CLDC. Die einzige Einschränkung betrifft die in den Klassen-Bibliotheken vorhandenen Schnittstellen. Die CDC hat nur die benötigten Schnittstellen beibehalten. - 18 - 3 Zusammenfassung Mit dem Boom mobiler Informationsgeräte war es aufgrund der Ressourcenlimitierung mobiler Endgeräte wie Mobiltelefone, Pager und auch PDAs der Einstiegsklasse notwendig, ein neues Java Gebiet zu definieren, um Java Anwendungen nutzen zu können. Durch die Konfigurationen stellt J2ME in diesem Bereiche geeignete Lösungen zur Verfügung. Nachdem in dieser Arbeit eine umfangreiche Einführung in das Konzept der CLDC und der CDC gegeben und wichtige Unterschiede im Klassenumfang zur J2SE erläutert wurden, wurde festgestellt, dass CLDC weitaus öfter zum Einsatz kommt als CDC. CLDC ist millionenfach in Handys und mobilen Organizer implementiert. Aus diesem Grund stellt die CLDC 1.1 neben MIDP 2.0 die wichtigste Grundlage für jede Anwendung der J2ME dar. Für den Bereich der Software-Entwicklung ist zu erwarten, dass der Umfang der standardisierten Java-APIs in nächster Zeit erheblich erweitert wird, damit auch andere Funktionen nach dem Java Motto "Ein Programm auf allen Handys ausführen zu können" entwickelt werden können. Allerdings sind aufgrund der eingeschränkten Fähigkeiten der mobilen Endgräte, wie z.B. geringer Programmspeicher, kleine Displays sowie begrenzte Eingabemöglichkeiten, im Vergleich zu dem Desktop PC, bei der J2ME differente Programmiertechniken erforderlich. Es wird erwartet, dass für den Einsatz auf PDAs eine dritte Konfiguration entwickelt wird, die die Abgrenzung zwischen den Hardwaregruppen noch genauer vornehmen kann. - 19 - Literaturverzeichnis [BM06] Ulrich Breymann, Heiko Mosemann: Java Me, Anwendungsentwicklung für Handys, PDA und Co., 2. Auflag, Hanser, 2006. [Es03] Sebastian Eschweiler: Das Einsteigerseminar, Java 2 Micro Edition, 2003. [Ga06] Gartner: Handy-Absatz übertrifft Milliardenmarke, Financial Times Deutschland, 22.11.2006. [GDC02] Vikas Gupta, Avnish Dass, Yashraj Chauhan: Keneth C. Louden: Wireless Programming with J2ME, Cracking the Code, Hungry Minds, 2002. [KH03] Michael Kroll, Stefan Haustein: J2ME Developper's Guide, JavaAnwendungen für mobile Geräte, Reilly, Markt + Technik Verlag, 2003. [RTP04] Roger Riggs, Antero Taivalsaari, Jim Van Peursem: Programming Wireless Devices with thr Java 2 Platform, Micro Edition, The java Series from the Source, Second Edition 2. 2004. [Ma02] Qusay H. Mahmoud: Learning Wireless Java, Help for New J2ME Developers., O'Reilly, 2002. [Sc07] Klaus-Dieter Schmatz: Java Micro Edition, 2. Auflag, dpunkt.verlag, 2007. [To02] Kim Topley: J2ME in s Nutshell, O'Reilly, 2002 [WH02] James White, David Hemphill: Java 2 Mirco Edition, Java in small thing, Manning, 2002. - 20 -
