Software ubiquitärer Systeme (SuS)€¦ · 10.07.2018 SuS: 06.3 Anwendungsentwicklung mit Java 5...

Software ubiquitärer Systeme (SuS)

Anwendungsentwicklung mit Java

https://ess.cs.tu-dortmund.de/DE/Teaching/SS2018/SuS/

Olaf Spinczyk

[email protected]://ess.cs.tu-dortmund.de/~os

AG Eingebettete SystemsoftwareInformatik 12, TU Dortmund

mailto:[email protected]

10.07.2018 SuS: 06.3 Anwendungsentwicklung mit Java 2

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 Java für eingebettete Systeme!Ein Java für eingebettete Systeme!


Die Java-Familie● Je nach Anforderungen

der Anwendungen bzw. Leistungsfähigkeit der Geräte bedient Oracle verschiedene Anwendungsdomänen mit unterschiedlichen Java-Plattformen.

Quelle: [1]

Nicht nur die Bibliotheken,sondern auch die virtuellenMaschinen unterscheidensich.

Nicht nur die Bibliotheken,sondern auch die virtuellenMaschinen unterscheidensich.


Inhalt● Motivation● Java Micro Edition● Java Card● Alternativen

– Android– .NET Compact

● Zusammenfassung


Die Java Micro Edition● Kurz: Java ME

– Sun Microsystems, Juni 1999● Zielmarkt

– Pager, PDAs– Mobiltelefone, Smartphones– Fernseher, Videorekorder, CD-Player

● Die meisten (klassischen) Mobiltelefone unterstützen heute Java ME● Abgespeckte Version der Standard Edition (Java SE)

– Weniger Speicherverbrauch– Keine schwergewichtigen Klassen (swing, awt, …)– Optimierte virtuelle Maschine (KVM)

Java 2Standard EditionAPI

JavaMicro EditionAPI


Java ME – Architektur● Die von Java ME abgedeckte Domäne ist riesig

– unterschiedlichste Geräte und Geräteklassen (Ressourcen)– unterschiedlichste Anwendungen (Anforderungen)

● Um die Java ME zu strukturieren, wurden zwei grundlegende Konzepte definiert:

Konfigurationen und Profile

LeistungsschwacheGeräte

LeistungsstärkereGeräte

...

Konfigurationen:Horizontale Aufteilungdes Marktes

Profile: Vertikale Marktaufteilung


Java ME – 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– CDC: Connected Device Configuration

● z.B. Smart Phones ab 2 MB Speicher, Set-Top-Boxes, High-End-PDAs– CLDC: Connected Limited Device Configuration

● z.B. Mobilfunkgeräte, um die 500 KB Speicher, einfache Applikationen● spezielle VM


Java ME – 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]


Java ME für Mobilgeräte

● 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

Betriebssystem

CLDC

Java VM (KVM)

MIDP

HerstellerspezifischeAPIs


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)– Zur Vermeidung von Sicherheitsproblemen und wegen des Overheads

● Benutzerdefinierte Class Loader● Reflection-Mechanismus● Threading-Fähigkeiten (eingeschränkt)

– Keine Thread Groups und Daemon Threads● Verifikation von Class Files

– Einsatz eines Pre-Verifiers


EntwicklungsprozessJava-Quelltext

Java Class-Dateien

Pre-verifizierteClass-Dateien

JAR-Paket

Anwendung aufdem Gerät

Compile

Preverification

Packaging

Deployment

javac ...

preverify ...

jar ...

emulator ...



● CLDC – Connected Limited Device Configuration – Low-Level-Funktionalität

● Umgang mit der Laufzeitumgebung, Ein-/Ausgabe– Besteht aus java.io, java.lang, java.util, java.microedition.io

● Allerdings nur Teilmengen der aus Java SE bekannten Klassen!● Die Semantik bleibt aber erhalten

Betriebssystem

Java VM (KVM)

MIDP


CLDC



● MIDP – Mobile Information Device Profile – MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung

● Netzwerkkommunikation● Datenhaltung● Benutzerschnittstelle

Betriebssystem

Java VM (KVM)


CLDC

MIDP


Mobile Information Device Profile● Minimalanforderungen

– Bildschirmauflösung von mind. 96x54 Pixeln– Keypad, Tastatur oder Touch Screen– 256 KB nicht-flüchtiger Speicher (für MIDP-Implementierung)– 128 KB RAM– 8 KB nicht-flüchtiger Speicher für persistente Anwendungsdaten– 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– Java ME-Applikationen bestehen aus 1 bis N MIDlets


Java ME: MIDlet-Lebenszyklus● MIDlets werden wie Applets von der Umgebung gesteuert

Paused

Destroyed

Active

Konstruktor

destroyApp()notifyDestroyed() pauseApp()

notifyPaused()

destroyApp()notifyDestroyed()

startApp()


Java ME: Midlet-Beispiel// 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) { } protected void pauseApp() { } protected void startApp() { Display.getDisplay(this).setCurrent(mMainForm); } public void commandAction(Command arg0, Displayable arg1) { notifyDestroyed(); }}

Man erbt von MIDlet.Man erbt von MIDlet.

Diese Methoden werden vomApplication Management System(AMS) des Mobilgeräts aufgerufen.

Diese Methoden werden vomApplication Management System(AMS) des Mobilgeräts aufgerufen.

So wird das AMS angewiesendas MIDlet zu beenden.So wird das AMS angewiesendas MIDlet zu beenden.


Java ME: Entwicklungsumgebung● Zum Bauen von Midlets benutzt man das …

Java ME SDK (aktuell 8.3)– Demo-Applikationen– Emulator– Alle sonstigen Werkzeuge


Java ME: Fazit● Pro:

– Durch Konfigurationen und Profile wird eine Familie von Java-Lö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-Mechanismus

– Entwickler müssen sich mit anderen Bibliotheken anfreunden



– Android– .NET Micro/Compact Framework

● Zusammenfassung


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

➔ Definitiv zu klein für Java ME!

C1

C2

C3

C4

C6

C7

C8

C5 GroundVppI/ORFU

VccResetClockRFU


Java Card: Anwendungen● Einsatzgebiete

– Krankenkassenkarten– Bankkarten (EC)– Handy-SIM-Karten– Ausweise– Ursprüngliches 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


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


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


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


Inhalt● Motivation● Java 2 Micro Edition● Java Card● Alternativen


● Zusammenfassung


Android● Open Handset Alliance (primär Google), 2007

– T-Mobile, Motorola, Samsung, ...● Vision:

“… accelerate innovation in mobile andoffer consumers a richer, less expensive,and better mobile experience.”

● Infrastruktursoftware-Plattform für Smartphones– Open Source

● Diverse Produkte heute verfügbar


Android: Architektur● Linux und Java – aber anders …

Die Dalvik-VM führt Java-Programmeaus, deren Bytecode in Dalvik-Bytecodeübersetzt wurde.

Die Dalvik-VM führt Java-Programmeaus, deren Bytecode in Dalvik-Bytecodeübersetzt wurde.


Android: Die Dalvik-VM● Benannt nach einer isländischen Stadt● Hauptunterschiede:

– Java-Bytecode ist stapelbasiert, Dalvik-Bytecode ist registerbasiert– Dalvik-Code wurde bis Android 2.2 nur interpretiert

● Danach: Trace-basierter JIT-Compiler● Heute: Übersetzung in Maschinencode zum Installationszeitpunkt

● Gründe:– Kompaktheit des Codes– JIT-Compiler wurde als unnötig erachtet, da die Performance-

kritischen Teile nativ ausgeführt werden (Kernel/Libraries)● inzwischen können Anwendungen auch „native code“ verwenden● JIT darf nicht zu viel Speicher benötigen

– Lizenzrechte?


Android: Größen (statisch)● common system libraries

– (U) 21 445 320 — 100%– (J) 10 662 048 — 50%– (D) 10 311 972 — 48%

● web browser app– (U) 470 312 — 100%– (J) 232 065 — 49%– (D) 209 248 — 44%

● alarm clock app– (U) 119 200 — 100%– (J) 61 658 — 52%– (D) 53 020 — 44%

(U) unkomprimierte jar-Datei(J) komprimierte jar-Datei(D) unkomprimierte dex-Datei

(U) unkomprimierte jar-Datei(J) komprimierte jar-Datei(D) unkomprimierte dex-Datei

Quelle: Dan Bornstein, Dalvik-VM-Entwickler

Der Grund ist allerdings nichtnur der kompaktere Bytecode,sondern auch ein schlaueresDateiformat.

Der Grund ist allerdings nichtnur der kompaktere Bytecode,sondern auch ein schlaueresDateiformat.


Android: Größen (dynamisch)

● JIT arbeitet Trace-basiert– Übersetzung auf Ebene von

Basisblöcken(statt ganzen Prozeduren)

– Ein Translation Cachepro Prozess (VM-Instanz)

● Trade-off zwischenPerformance undSpeicherbedarfakzeptabel

Quelle: A JIT Compiler for Android’s Dalvik VM Ben Cheng, Bill Buzbee, May 2010


Android Runtime (ART) (1)● Kompilierung von Android-Apps in Maschinencode zum

Installationszeitpunkt– ab Android 4.4 möglich

● Vorteile:– Dalvik-VM und JIT werden nicht mehr benötigt → weniger Speicher– Kein Tracing/Übersetzen zur Laufzeit → weniger Energie– Linux lädt Programme inkrementell → starten schneller– Alle Programmteile liegen in Maschinencode vor → laufen schnell

● Nachteile:– Keine dynamischen Optimierungen → teilweise auch langsamer


Android: ART (2)● Partielle Code-Spezialisierung in JIT-Compiler

– nicht bei ARTint myfunc(int par1, int par2, int par3) { int r = 47; if (par1*par2 > 5) { int i; for (i=0; i<par1*par2;i++) { r+=par3*i; } } else r = par1+par2+par3 return r;}

int myfunc(int par1, int par2, int par3) { int r = 47; int i = 35; while (--i) r += i + i; return r;}

int myfunc(int par1, int par2, int par3) { return 16;}

myfunc(7,5,2) myfunc(2,2,12)

Basierend auf der Ausführungshäufigkeit von Funktionen mit bestimmten Parametern (ermittelt vom Trace-JIT) werden Funktionen spezialisiert. Entsprechende Aufrufe werden umgeleitet.

Basierend auf der Ausführungshäufigkeit von Funktionen mit bestimmten Parametern (ermittelt vom Trace-JIT) werden Funktionen spezialisiert. Entsprechende Aufrufe werden umgeleitet.

Quelle: c't 13/2015 „Endlich kompiliert“


Android: ART (3)● Und wie steht's nun mit der Performance?

● In c't 13/2015 wurden 9 Benchmarks verglichen(relative Performance im Vergleich zu Dalvik inkl. JIT)

– Android 4.4/ARM: 99% bis 184%, Durchschnitt 133%– Android 5.1/ARM: 65% bis 238%, Durchschnitt 149%– Android 4.4/Intel: 28% bis 179%, Durchschnitt 74%– Android 5.1/Intel: 47% bis 176%, Durchschnitt 106%

● Fazit:– ART hat das Potential die Performance deutlich zu verbessern– Kinderkrankheit auf Intel-basierten Android-Geräten


Android: Fazit● Android ist für Smartphones ausgelegt

– Skalierbarkeit ist kein Thema– Annahme: typischerweise 64–512 MB Speicher, 250–1000 MHz CPU

● Heute viel mehr vorhanden!● Android zeigt, dass …

– die Java-VM nicht unbedingt perfekt geeignet ist, um kleine Systeme zu bauen

● Dalvik-Bytecode ist signifikant kleiner– Ausführung von kompiliertem Maschinencode und Portabilität kein

Widerspruch sein müssen● Übersetzung zum Installationszeitpunkt bei ART


.NET-Framework für eingeb. Systeme?● 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

– Anwendungsentwicklungin MS Visual Studio

– Diverse Bibliotheken● Benutzerschnittstelle, Kommunikation, …● Allerdings an diversen Stellen beschnitten

➔ Größenreduktion des .NET-Frameworks …– Compact: erfordert 12 MB– Micro: erfordert 256 KB Flash, 64KB RAM (läuft ohne OS, kein JIT)

Quelle: msdn.microsoft.com




● Zusammenfassung


Zusammenfassung● Java-Umgebungen bilden eine Produktlinie

– Skalierbarkeit von 8-Bit-Chipkarten bis 64-Bit-Serversysteme● Bei den kleineren Varianten gibt es Einschränkungen

– z.B. keine Garbage Collection bei Java Card● Es gibt auch Alternativen

– Dalvik- und MSIL-Programme haben kompakteren Code– Klassische Mobiltelefone und damit auch Java ME werden von

Smartphones verdrängt


Literatur[1] M. de Jode, Programming Java 2 Micro Edition on Symbian OS, ISBN

0-470-09223-8, Wiley, 2004.[2] Java Card Platform Specification 2.2.2, Sun Microsystems.

Software ubiquitärer Systeme (SuS)€¦ · 10.07.2018 SuS: 06.3 Anwendungsentwicklung mit Java 5...

Documents

Transcript of Software ubiquitärer Systeme (SuS)€¦ · 10.07.2018 SuS: 06.3 Anwendungsentwicklung mit Java 5...