DOC

Java auf Mobilen Systemen

By Samantha Butler,2014-04-24 13:37
6 views 0
Java auf Mobilen Systemen

Java auf Mobilen Systemen

Von Sven Kerkling

    1.Java

    Es gibt zwei verschieden Java Versionen (oder besser Plattform), für die Entwicklung von Java Programmen auf Mobile Devices und Pocket PC’s sowie Handhelds. Zuerst gab es da Personal Java, was aus der J2SE Plattform entstanden ist, und J2ME, welches die Weiterentwicklung von Personal Java sein soll.

J2ME besteht im Grunde genommen aus zwei verschiedenen

    Konfigurationen und mehreren Profilen, wobei Personal Java als Profil in das J2ME in abgewandelter Version wieder zu finden ist.

1.1 Personal Java

    Wie bereits oben erwähnt ist Personal Java, der erste Versuch mit Java Programme für Mobile Devices zu schreiben.

    Es ist eine abgespeckte J2SE Version von Java.

    Personal Java baut auf J2SE Version JDK 1.1 auf, und somit steht zum Beispiel das Package Swing überhaupt nicht zu Verfügung in Personal Java.

*note*

    Zum Zeitpunkt des Vortrages gehörte Personal Java noch zum festen Produkten von Sun. Auch war es für einige der bestehenden VM für Pocket PC und Handhelds die gültige Spezifikation, d.h. J2ME hatte sich noch nicht am Markt durchgesetzt. Nun hat aber Sun für Personal Java eine EOL (End of Life) Vorankündigung geschrieben, d.h. Personal Java verschwindet nun vom langsam vom Markt und alle Entwickler sollten ihre Produkte auf den J2ME Standard umschreiben.

    *note*

1.2 J2ME

J2ME besteht aus den zwei Konfigurationen CDC und CLDC, sowie

verschieden Profile, die aber auch gleichzeitig umsetzbar sind.

    Da J2ME ein sehr grosses Spektrum von Geräten abdeckt, existieren mehrere Konfigurationen, die unterschiedliche Anforderungen an die JVM und an die Ausstattung der Codebibliothek definieren. Die Connected Device Configuration (CDC) beispielsweise beschreibt eine J2ME-Konfiguration für Communicator oder Bildtelefone, die Connected Limited Device Configuration (CLDC) eine solche für Handys, PDA und Pocket PC . Innerhalb der Konfigurationen gibt es weitere Unterteilungen, welche die Bedürfnisse einer bestimmten Gerätegruppe noch enger umreissen. Diese Unterteilungen werden Profile genannt.

    Java-Applikationen für mobile Geräte müssen dem Mobile Information Device Profile (MIDP) entsprechen. Ausgehend von der Abkürzung MIDP und in Anlehnung an die Bezeichnung „Java-Applet“ beginnt sich für

    dynamisch zuladbare Handy-Software der Begriff MIDlet einzubürgern. Ein typisches Handy kann 120 bis 150 KByte Speicherplatz

    für Java zur Verfügung stellen; die Grösse eines MIDlet ist auf 30 KByte beschränkt.

1.3 Unterschiede J2SE und J2ME

Es gibt bei J2ME einige bedeutende Einschnitte im Gegensatz zu J2SE.

1.3.1 Keine Gleitkomma-Berechnungen

Wie auch bei anderen Programmiersprachen gibt es für PocketPC und

    Handy keine Gleitkommaunterstützung, die aber auf fehlende

    Hardwareunterstützung rückzuführen ist.

Es gibt allerdings bei Java eine Softwareseitige Emulation von

    Gleitkommazahlen über das mitgelieferte Paket MathFP.

1.3.2 kein finalize()

Die Methode finalize, die jeden Objekt zugeordnet ist im J2SE und vom

    Garbage Collector aufgerufen wird, fehlt bei der CLDC Konfiguration.

1.3.3 Begrenzte Internationalisierung

Grundlegende Konvertierungen zwischen Byte Streams und Unicode sind

    möglich, weitergehende Konzepte wie Locale, ResourceBundle und

    DateFormat sind in J2ME nicht definiert.

1.3.4 Begrenztes Exceptionhandling

Im Wesentlichen ist das Error-Handling für CLDC auf zwei Klassen

    beschränkt:

     java.lang.VirtualMachineError und

     java.lang.OutOfMemoryError.

    Dieser Schritt resultiert aus den Ressourcenbeschränkungen der Geräte.

    Auch soll sich der Programmierer nicht mit gerätespezifischen Fehlern

    befassen, um Plattformunabhängigkeit zu gewährleisten.

1.4 J2ME Architektur

1.4.1 Java Virtual Machine Layer - KVM

Die Kilobyte Virtual Machine (KVM) ist der Vermittler zwischen der

    laufenden Java-Applikation und dem darunterliegenden OS

    (Betriebssystem). Die KVM läuft auf 16/32bit RISC/CISC-Prozessoren.

    Die Größe der KVM wurde auf 50-80KByte reduziert, was es überhaupt

    erst ermöglicht hat, auf einem eingebetteten System zu laufen. Sie

    verwendet wenig Speicher für die dynamisch gelinkten Bibliotheken.

    Somit können Applikationen mit nur 128kByte laufen. Obwohl die KVM

    in C implementiert ist, ist sie durch die allgemein gehaltene Spezifikation

    dennoch portabel. Sie ist auf allen Plattformen einsetzbar, für die ein C-

    Compiler existiert.

1.4.2 Configuration Layer

Die Konfigurationen beschreiben die verfügbaren Grundfunktionen der

    virtuellen Maschine für eine Klasse von Geräten mit ähnlicher Leistungsfähigkeit. Dies schließt sowohl die Low-Level Klassen für Ein- und Ausgabe ein, als auch den Java Sprachumfang, etwa ob

    Fließkommazahlen unterstützt werden (wie bereits oben erwähnt). Eine Konfiguration umfasst eine virtuelle Maschine, Klassenbibliotheken und API’s, die auf die Eigenschaften dieser Geräte zugeschnitten sind.

    Im J2ME sind zwei Konfigurationen umgesetzt, welche aufgrund Ihrer Anforderungen an die Zielplattform sehr unterschiedliche Untermengen der J2ME Klassen unterstützen. Die Connected Limited Device Configuration (CLDC) für Mobiltelefone, Pager und PDAs

    und die Connected Device Configuration (CDC) für etwas

    leistungsfähigere Geräte, wie Settopboxen, Bildtelefone und Spielkonsolen.

1.4.3 CDC

    CDC zielt auf leistungsfähigere Geräte, wie z. B. Webpads, Bildtelefone, Spielkonsolen und PDAs, mit einer mit den Pocket PCs vergleichbaren Leistungsfähigkeit, ab.

    Randdaten, welche diese Plattformen unterstützen müssen, sind Systemspeicher von mindestens 256kB RAM und 512kB ROM sowie Netzwerkverbindungsmöglichkeiten mit mehr als 9600Bps.

    Die CDC (Connected Device Configuration) beinhaltet eine komplette JVM, die Java 2 CVM (Connected Virtual Machine) und die minimal erforderlichen API Klassen für das System. Für Applikationen wird zusätzlich ein Profil benötigt, das „Foundation Profile“.

    Dies beinhaltet alle übrigen Klassen und APIs. Bei Bedarf (z.B. für GUI) müssen noch zusätzliche Profile verwendet werden.

1.4.3.1 Profile im CDC

    Das Interessanteste Profil, für Mobile Computing, im CDC ist zurzeit das PDA-Profil, welches schon länger angekündigt ist aber noch nicht veröffentlicht wurde.

    Man erwartet, dass dadurch mehr mit den doch schon bedeutend leistungsstarken PDA und Pocket PC machbar ist, wie z.B. Gleitkomma Zahlen und ähnliche Sachen die im CLDC nicht möglich sind.

1.4.4 CLDC

    Die CLDC-Konfiguration ist für kleinere Geräte, wie einfache PDAs und Mobiltelefone definiert. Sie verfügen über einen Speicher von 128 bis 512 kB. Sie können Netzverbindungen mit maximal 9600 Baud betreiben und arbeiten in der Regel mit Batterie. Das CLCD nutzt eine eigene virtuelle Maschine, die KVM. Für den Palm-Pilot ist zum Beispiel eine Implementierung der KVM verfügbar, ebenfalls auch für Mobiltelefone. Hersteller wie IBM (s.u.) haben eigene virtuelle Maschinen im Angebot, die oft schneller in der Ausführung sind.

Kurze Zusammenfassung:

    Die Pakete der J2ME sind eine Teilmenge der J2SE, insbesondere: java.lang (VM-Systemklassen)

    java.io (Datei Ein-/Ausgabe)

    java.util (Datenstrukturen)

    java.net

    java.text (Minimale Funktionalität für Internationalisierung, speziell Fehlermeldungen)

    java.security (Minimale Funktionalität, Verschlüsselung für serialisierte Objekte)

    Für Mobiltelefone existiert bereits das Mobile Information Device Profile (MIDP), das GUI-Klassen wie auch Datenbanklassen für die persistente Datenhaltung auf Mobiltelefonen beinhaltet. Da die CLDC-KVM für Geräte spezifiziert wurde, deren Prozessoren möglicherweise keine Fließpunktarithmetik unterstützen, stehen die Datentypen float und double nicht zur Verfügung. Eine Lösung für dieses Problem stellt zum Beispiel

    die Bibliothek MathFP dar, die Festkomma-Arithmetik auf Basis des 32-Bit Integer-Datentyps der KVM zur Verfügung stellt. Außerdem fehlt der KVM aus Sicherheitsgründen die Unterstützung für das Java Native Interface (JNI), wodurch dem Entwickler der Zugriff auf

    Betriebsystemaufrufe verwährt bleibt. Darüber hinaus ist die Reflection-API stark eingeschränkt, wie auch die Objekt Finalisation, sodass der Java Garbage Collector nicht unterstützt wird.

1.4.4.1 Profile im CLDC

-MIDP

Voraussetzungen

    Um das MIDP für ein Gerät zu implementieren muss die Hard- und Software eines mobilen Geräts (MID) gewisse Voraussetzungen erfüllen:

Hardware-Voraussetzungen

    Anzeige: Bildschirmgröße 96 x 54

    Farbtiefe 1 bit

    Inputmöglichkeit

    Speichermöglichkeit

Software-Voraussetzungen

    Die Variation an Betriebssystemen in MID-Geräten ist relativ groß. Einige Betriebssysteme bieten ein ausgereiftes Dateisystem an und andere stellen nichts derartiges zur Verfügung. Aufgrund der großen Unterschiede setzt die MIDPSpezifikation die folgenden Voraussetzungen an das

    Betriebsystem eines MID voraus.

    Kernel

    Storage

    Networking

    Timers

    Display

    Input Mechanismen

    MIDlets sind so wie Servlets, daher gibt es keine main-Klasse und System.exit() führt nicht wie gewohnt zum Abbruch des Programms.

    Auch gibt es bei Midlets Timer, die die Aktivitäten der Applets im Hintergrund steuern.

-Bluetooth

    Über dieses Profil soll Zugriff auf alle Verbindungen zwischen mehreren Geräten hergestellt werden können.

    Auch Inforat (iRDA) soll unterstüzt werden.

-

    Es gibt noch etliche weitere Profile im CLDC.

Hier noch einige aufgezählt:

High-Level: Ziel ist Portabilität der Programme

    Low-Level: Geringe Abstraktion, und damit auch erschwerte Portabilität.

    High und Low Level sind Abwandlungen der MIDP Profils

Report this document

For any questions or suggestions please email
cust-service@docsford.com