SuS-06.2: Produktlinien mit C++-Templates

Software ubiquitärer Systeme
Anwendungsentwicklung mit Java
Olaf Spinczyk
Arbeitsgruppe Eingebettete Systemsoftware
Lehrstuhl für Informatik 12
TU Dortmund
[email protected]
http://ess.cs.uni-dortmund.de/~os/
http://ess.cs.tu-dortmund.de/DE/Teaching/SS2011/SuS/
1
Motivation
●
Probleme mit C und C++
effizienter Code aber unsicher
● eingeschränkte Portabilität
●
- verschiedene Betriebssysteme und GUI-Bibliotheken: z.B. in
Mobiltelefonen Symbian OS, Windows CE, Linux Varianten
●
Sichere C++ Dialekte
weniger effizienter Code
● mangelnde Verbreitung/Standardisierung
●
●
Was ist die Alternative?
Ein
Ein Java
Java für
für eingebettete
eingebettete Systeme!
Systeme!
06.3 – Anwendungsentwicklung mit Java
2
Die Java-Familie
●
Je nach Anforderungen der Anwendungen bzw. Leistungsfähigkeit
der Geräte bedient Sun verschiedene Anwendungsdomänen mit
unterschiedlichen Java Plattformen.
Nicht
Nicht nur
nur die
die Bibliotheken
Bibliotheken
sondern
sondern auch
auch die
die virtuellen
virtuellen
Maschinen
Maschinen unterscheiden
unterscheiden
sich.
sich.
Quelle: [1]
06.3 – Anwendungsentwicklung mit Java
3
Inhalt
●
Motivation
●
Java 2 Micro Edition
Java Card
Alternativen
●
●
Android
● .NET Compact
●
●
Zusammenfassung
06.3 – Anwendungsentwicklung mit Java
4
Die Java 2 Micro Edition
●
Kurz: J2ME
●
●
Sun Microsystems, Juni 1999
Zielmarkt
●
Pager
●
Mobiltelefone, Smartphones
●
PDAs
●
Fernseher, Videorekorder, CD Player
Java 2
Standard Edition
API
Java
Micro Edition
API
●
Alle besseren Mobiltelefone unterstützen heute Java ME
●
Abgespeckte Version Standard Edition (J2SE)
●
Weniger Speicherverbrauch
●
Keine schwergewichtigen Klassen (swing, awt, …)
●
Optimierte virtuelle Maschine (KVM)
06.3 – Anwendungsentwicklung mit Java
5
J2ME Architektur
●
Die von J2ME abgedeckte Domäne ist riesig
●
unterschiedlichste Geräte und Geräteklassen (Ressourcen)
●
unterschiedlichste Anwendungen (Anforderungen)
Um die J2ME zu strukturieren, wurden zwei grundlegende
Konzepte definiert:
Konfigurationen und Profile
Leistungsstärkere
Geräte
Konfigurationen:
Horizontale Aufteilung
des Marktes
...
●
Leistungsschwache
Geräte
Profile: Vertikale Marktaufteilung
06.3 – Anwendungsentwicklung mit Java
6
J2ME Konfigurationen
●
Definiert Geräteklassen anhand verfügbarer Ressourcen
●
●
●
CPU-Klasse, Speicher, Netzwerkanbindung
Entscheidet über …
●
die verwendete virtuelle Maschine sowie
●
APIs für elementare Funktionen.
➔
… die Java Ausführungsumgebung
Bisher wurden zwei Konfigurationen festgelegt
●
CLDC: Connected Limited Device Configuration
- z.B. Mobilfunkgeräte, um die 500 KB Speicher, einfache Applikationen
- spezielle VM
●
CDC: Connected Device Configuration
- z.B. Smart Phones ab 2 MB Speicher, Set-Top-Boxes, High-End PDAs
06.3 – Anwendungsentwicklung mit Java
7
J2ME Profile
●
Hängen von der jeweiligen
Anwendungsdomäne ab
●
Definieren verfügbare APIs
●
Sorgen für Portabilität
●
Haben Abhängigkeiten
●
Beispiele:
●
MIDP (Mobile Information Device P.)
- Netzwerk-Kommunikation
- Einfache Benutzerschnittstelle
- Datenspeicherung
●
Personal Profile
- Komplettes AWT
- Ausführungsumgebung für Applets
Quelle [1]
06.3 – Anwendungsentwicklung mit Java
8
J2ME für Mobilgeräte
MIDP
Herstellerspezifische
APIs
CLDC
Java VM (KVM)
Betriebssystem
●
KVM - Kilobyte Virtual Machine
40 – 80 KB groß (je nach Compiler)
● Implementiert in C (ca. 36.000 Zeilen)
● Für Geräte mit mindestens …
●
- 160 KB Speicher und
- 16 oder 32 Bit CPU
06.3 – Anwendungsentwicklung mit Java
9
KVM: Was fehlt?
●
Unterstützung für Object.finalize()
●
●
Wird auch praktisch nicht verwendet
Fehlerbehandlungsfähigkeiten (eingeschränkt)
●
Es gibt lediglich 3 Fehler-Klassen
- java.lang.Error, java.lang.OutOfMemory und java.lang.VirtualMachineError
●
Java Native Interface (JNI)
●
●
●
●
Benutzerdefinierte Class Loader
Reflection-Mechanismus
Threading-Fähigkeiten (eingeschränkt)
●
●
Zur Vermeidung von Sicherheitsproblemen und
wegen des Overheads
Keine Thread Groups und Daemon Threads)
Verifikation von Class Files
●
Einsatz eines Pre-Verifiers
06.3 – Anwendungsentwicklung mit Java
10
Entwicklungsprozess
Java-Quelltext
Compile
javac ...
Preverification
preverify ...
Packaging
jar ...
Deployment
emulator ...
Java Class-Dateien
Pre-verifizierte
Class-Dateien
JAR-Paket
Anwendung auf
dem Gerät
06.3 – Anwendungsentwicklung mit Java
11
J2ME für Mobilgeräte
MIDP
Herstellerspezifische
APIs
CLDC
Java VM (KVM)
Betriebssystem
●
CLDC - Connected Limited Device Configuration
●
Low-Level Funktionalität
- Umgang mit der Laufzeitumgebung, Ein-/Ausgabe
●
Besteht aus of java.io, java.lang, java.util, java.microedition.io
- Allerdings nur Teilmengen der aus J2SE bekannten Klassen!
- Die Semantik bleibt aber erhalten
06.3 – Anwendungsentwicklung mit Java
12
J2ME für Mobilgeräte
MIDP
Herstellerspezifische
APIs
CLDC
Java VM (KVM)
Betriebssystem
●
MIDP – Mobile Information Device Profile
●
MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung
- Netzwerkkommunikation
- Datenhaltung
- Benutzerschnittstelle
06.3 – Anwendungsentwicklung mit Java
13
J2ME: Mobile Information Device Profile
●
Minimalanforderungen
Bildschirmauflösung von mind. 96x54 Pixeln
● Keypad, Tastatur oder Touch Screen
● 256 KB nicht-flüchtiger Speicher
● 128 KB RAM
● 8 KB nicht-flüchtiger Speicher für persistente Daten
● Bi-direktionale Netzwerkverbindung
●
●
MIDP 2.0 Packages
●
●
javax.microedition.lcdui, javax.microedition.lcdui.game,
javax.microedition.media, javax.microedition.media.control,
javax.microedition.midlet, javax.microedition.pki,
javax.microedition.rms
Ausführung von Midlets
●
J2ME-Applikationen bestehen aus 1 bis N MIDlets
06.3 – Anwendungsentwicklung mit Java
14
J2ME: Midlet-Lebenszyklus
●
MIDlets werden wie Applets von der Umgebung gesteuert
Konstruktor
Paused
destroyApp()
notifyDestroyed()
startApp()
pauseApp()
notifyPaused()
Destroyed
06.3 – Anwendungsentwicklung mit Java
Active
destroyApp()
notifyDestroyed()
15
J2ME: Midlet-Beispiel
Man
Man erbt
erbt von
von MIDlet.
MIDlet.
// Zur Vereinfachung ohne Exceptions ...
public class HelloMIDlet extends MIDlet
implements CommandListener {
private Form mMainForm;
public HelloMIDlet() {
mMainForm = new Form("HelloMIDlet");
mMainForm.append(new StringItem(null, "Hello, MIDP!"));
mMainForm.addCommand(new Command("Exit", Command.EXIT, 0));
mMainForm.setCommandListener(this);
}
protected void destroyApp(boolean arg0) {
Diese
Diese Methoden
Methoden werden
werden vom
vom
}
Application
Application Management
Management System
System
protected void pauseApp() {
(AMS)
(AMS) des
des Mobilgeräts
Mobilgeräts aufgerufen.
aufgerufen.
}
protected void startApp() {
Display.getDisplay(this).setCurrent(mMainForm);
}
public void commandAction(Command arg0, Displayable arg1) {
notifyDestroyed();
So
So wird
wird das
das AMS
AMS angewiesen
angewiesen
}
das
das MIDlet
MIDlet zu
zu beenden.
beenden.
}
06.3 – Anwendungsentwicklung mit Java
16
J2ME: Demo
●
Zum Bauen von Midlets benutzt man das …
Java ME SDK (aktuell 3.0)
Demo-Applikationen
● Emulator
● Alle sonstigen Werkzeuge
●
06.3 – Anwendungsentwicklung mit Java
17
J2ME: Fazit
●
Pro
●
Durch Konfigurationen und Profile wird eine Familie von JavaLösungen bereitgestellt
- Damit skaliert der Ressourcenverbrauch
●
●
Standardisierte domänenspezifische Bibliotheken
●
Die kvm benötigt erstaunlich wenig Speicher
Contra
●
Die kvm ist leider langsam
●
Leichte Einschränkungen bzgl. der Sprache müssen hingenommen
werden
- z.B. kein Reflection
●
Entwickler müssen sich mit anderen Bibliotheken anfreunden
06.3 – Anwendungsentwicklung mit Java
18
Inhalt
●
Motivation
●
Java 2 Micro Edition
Java Card
Alternativen
●
●
Android
● .NET Compact
●
●
Zusammenfassung
06.3 – Anwendungsentwicklung mit Java
19
Java Card: Hardware
●
Eine Java-Lösung für Smart Cards
(Chipkarten mit Prozessor)
●
Hardware-Eigenschaften
Stromversorgung durch Lesegerät
● Interaktion lediglich mit dem Lesegerät
●
- Serielle Schnittstelle, Standardprotokoll
●
Enthalten Universalprozessor
- 8-32 Bit, 3,5-5 MHz
●
Extrem wenig Speicher
- 16-32 KB ROM
- 0,5-1 KB RAM
- 8-16 KB EEPROM
➔
Vcc
Reset
Clock
RFU
C1
C2
C3
C4
C5
C6
C7
C8
Ground
Vpp
I/O
RFU
Definitiv zu klein für J2ME!
06.3 – Anwendungsentwicklung mit Java
20
Java Card: Anwendungen
●
Einsatzgebiete
Krankenkassenkarten
● Bankkarten (EC)
● Handy-SIM-Karten
● Ausweise
➔ Ziel: nur eine Karte für viele Applikationen
●
●
Anforderungen an die Java Card Plattform
●
Sicherheit und Zuverlässigkeit
- Verwaltung und Isolierung der Applikationen auf der Karte
Extrem geringer Ressourcenverbrauch
● Für die Domäne passende standardisierte Packages
● Portabilität
● Kompatibilität mit existierenden Standards
●
06.3 – Anwendungsentwicklung mit Java
21
Java Card: Was fehlt?
●
Dynamisches Klassenladen
●
Security Manager
●
Garbage Collection
●
Threads
●
Klonen von Objekten
●
Mehrdimensionale Felder
●
Datentypen char, double, float und long
●
Die Java Card API beschränkt sich auf folgende Pakete
●
java.lang, javacard.framework, javacard.security, javacardx.crypto
06.3 – Anwendungsentwicklung mit Java
22
Java Card: Applets ...
●
sind persistente Zustandsautomaten, die auf Nachrichten
des Lesegeräts reagieren.
●
haben (mindestens) folgende Methoden
●
install
- Erzeugung und Registrierung der Applet-Instanz
●
select
- Das Lesegerät spricht das Applet an
●
process
- Interpretation der Nachrichten (APDUs) vom Lesegerät
●
deselect
- Das Lesegerät beendet die Kommunikation mit dem Applet
06.3 – Anwendungsentwicklung mit Java
23
Java Card: Fazit
●
●
Pro
●
Plattformunabhängige Entwicklung für Smart Cards
●
Unterstützung mehrerer Applikationen auf einer Karte
●
Dynamische Installation/Deinstallation von Applets
●
Standardisierte Bibliotheken
●
Nutzbarkeit von Java Know-How
Contra
●
Die Sprache ist zwar Java, das Programmiermodell aber nicht.
●
Essentielle Sprachelemente fehlen
●
Deutliche Nachteile hinsichtlich der Performance
●
Vergleichsweise hohe Ressourcenanforderungen
06.3 – Anwendungsentwicklung mit Java
24
Inhalt
●
Motivation
●
Java 2 Micro Edition
Java Card
Alternativen
●
●
Android
● .NET Compact
●
●
Zusammenfassung
06.3 – Anwendungsentwicklung mit Java
25
Android
●
Open Handset Alliance (primär Google), 2007
●
T-Mobile, Motorola, Samsung, ...
●
Vision:
“... accelerate innovation in mobile and
offer consumers a richer, less expensive,
and better mobile experience.”
●
Infrastruktursoftware-Plattform für Smartphones
●
●
Open Source
Diverse Produkte inzwischen verfügbar
06.3 – Anwendungsentwicklung mit Java
26
Android: Architektur
●
Linux und Java – aber anders ...
06.3 – Anwendungsentwicklung mit Java
27
Android: Architektur
●
Linux und Java – aber anders ...
Die
Die Dalvik-VM
Dalvik-VM führt
führt Java-Programme
Java-Programme
aus,
aus, deren
deren Bytecode
Bytecode in
in Dalvik-Bytecode
Dalvik-Bytecode
übersetzt
übersetzt wurde.
wurde.
06.3 – Anwendungsentwicklung mit Java
28
Android: Die Dalvik-VM
●
●
Benannt nach einer isländischen Stadt
Hauptunterschiede
●
Java-Bytecode ist stapelbasiert, Dalvik-Bytecode ist registerbasiert
- Java-Bytecode lässt sich nicht (direkt) ausführen
- Ein Übersetzungschritt ist erforderlich
●
Dalvik Code wird grundsätzlich interpretiert
- (noch) kein JIT-Compiler
●
Gründe
Kompaktheit des Codes
● JIT-Compiler wurde als unnötig erachtet, da die Performancekritischen Teile nativ ausgeführt werden (Kernel/Libraries)
● Lizenzrechte?
●
06.3 – Anwendungsentwicklung mit Java
29
Android: Größenvergleich
●
●
●
common system libraries
●
(U) 21445320 — 100%
●
(J) 10662048 — 50%
●
(D) 10311972 — 48%
(U)
(U) unkomprimierte
unkomprimierte jar-Datei
jar-Datei
(J)
(J) komprimierte
komprimierte jar-Datei
jar-Datei
(D)
(D) unkomprimierte
unkomprimierte dex-Datei
dex-Datei
web browser app
●
(U) 470312 — 100%
●
(J) 232065 — 49%
●
(D) 209248 — 44%
alarm clock app
●
(U) 119200 — 100%
●
(J) 61658 — 52%
●
(D) 53020 — 44%
Der
Der Grund
Grund ist
ist allerdings
allerdings nicht
nicht
nur
nur der
der kompaktere
kompaktere Bytecode,
Bytecode,
sondern
sondern auch
auch eine
eine schlaueres
schlaueres
Dateiformat.
Dateiformat.
Quelle: Dan Bornstein, Dalvik VM Entwickler
06.3 – Anwendungsentwicklung mit Java
30
Android: Fazit
●
●
Android ist für Smartphones ausgelegt
●
Skalierbarkeit ist kein Thema
●
Annahme: typische 64-512 MB Speicher, 250-1000 MHz CPU
Android zeigt, dass die Java-VM nicht unbedingt perfekt
geeignet ist, um kleine Systeme zu bauen
●
Dalvik-Bytecode ist signifikant kleiner
06.3 – Anwendungsentwicklung mit Java
31
.NET Compact Framework
●
●
Microsoft
Ermöglicht .NET auf Windows CE/Mobile-Geräten
●
Moderne Zwischensprache (MSIL) für mehrere Quellsprachen
- C#, VB, J#, C++, …
- Ausgelegt auf JIT-Compiler
Anwendungsentwicklung in MS Visual Studio
● Diverse Bibliotheken
●
- Benutzerschnittstelle, Kommunikation, …
- Allerdings an diversen Stellen beschnitten
➔
Größenreduktion des .NET Frameworks
von 20 MB auf 1,35 MB!
06.3 – Anwendungsentwicklung mit Java
32
Inhalt
●
Motivation
●
Java 2 Micro Edition
Java Card
Alternativen
●
●
Android
● .NET Compact
●
●
Zusammenfassung
06.3 – Anwendungsentwicklung mit Java
33
Zusammenfassung
●
Java-Umgebungen bilden eine Produktlinie
●
●
Bei den kleineren Varianten gibt es Einschränkungen
●
●
Skalierbarkeit von 8 Bit Chipkarten bis 64 Bit Serversystemen
z.B. keine Garbage Collection bei Java Card
Es gibt auch Alternativen
●
Dalvik- und MSIL-Programme haben kompakteren Code
●
J2ME hat bisher aber noch die größte Verbreitung
06.3 – Anwendungsentwicklung mit Java
34
Literatur
[1]
[2]
M. de Jode, Programming Java 2 Micro Edition on Symbian
OS, ISBN 0-470-09223-8, Wiley, 2004.
Java Card Platform Specification 2.2.2, Sun Microsystems.
06.3 – Anwendungsentwicklung mit Java
35