SuS-06.3: Anwendungsentwicklung mit Java
Werbung
Software ubiquitärer Systeme (SuS) Anwendungsentwicklung mit Java https://ess.cs.tu-dortmund.de/DE/Teaching/SS2016/SuS/ Horst Schirmeier, Olaf Spinczyk [email protected] https://ess.cs.tu-dortmund.de/~hsc AG Eingebettete Systemsoftware Informatik 12, TU Dortmund 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.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 2 Die Java-Familie ● Je nach Anforderungen der Anwendungen bzw. Leistungsfähigkeit der Geräte bedient Oracle 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. 06.07.2016 Quelle: [1] SuS: 06.3 Anwendungsentwicklung mit Java 3 Inhalt ● Motivation ● Java Micro Edition ● Java Card ● Alternativen ● – Android – .NET Compact Zusammenfassung 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 4 Die Java Micro Edition ● Kurz: Java ME Sun Microsystems, Juni 1999 Zielmarkt – ● Java 2 Standard Edition API Pager, PDAs – Mobiltelefone, Smartphones – Fernseher, Videorekorder, CD-Player Die meisten (klassischen) Mobiltelefone unterstützen heute Java ME – ● ● Java Micro Edition API Abgespeckte Version der Standard Edition (Java SE) – – – Weniger Speicherverbrauch Keine schwergewichtigen Klassen (swing, awt, …) Optimierte virtuelle Maschine (KVM) 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 5 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 Leistungsstärkere Geräte ... Konfigurationen: Horizontale Aufteilung des Marktes Leistungsschwache Geräte Profile: Vertikale Marktaufteilung 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 6 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 ● ● 06.07.2016 z.B. Mobilfunkgeräte, um die 500 KB Speicher, einfache Applikationen spezielle VM SuS: 06.3 Anwendungsentwicklung mit Java 7 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 ● ● 06.07.2016 Komplettes AWT Ausführungsumgebung für Applets SuS: 06.3 Anwendungsentwicklung mit Java Quelle: [1] 8 Java ME für Mobilgeräte Herstellerspezifische APIs MIDP 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 … ● ● 06.07.2016 160 KB Speicher und 16- oder 32-Bit-CPU SuS: 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) – 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 06.07.2016 SuS: 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.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 11 Java ME für Mobilgeräte Herstellerspezifische APIs MIDP CLDC Java VM (KVM) Betriebssystem ● CLDC – Connected Limited Device Configuration – Low-Level-Funktionalität ● – Besteht aus java.io, java.lang, java.util, java.microedition.io ● ● 06.07.2016 Umgang mit der Laufzeitumgebung, Ein-/Ausgabe Allerdings nur Teilmengen der aus Java SE bekannten Klassen! Die Semantik bleibt aber erhalten SuS: 06.3 Anwendungsentwicklung mit Java 12 Java ME für Mobilgeräte Herstellerspezifische APIs MIDP CLDC Java VM (KVM) Betriebssystem ● MIDP – Mobile Information Device Profile – MIDP stellt Kernfunktionen für Mobilgeräte zur Verfügung ● ● ● 06.07.2016 Netzwerkkommunikation Datenhaltung Benutzerschnittstelle SuS: 06.3 Anwendungsentwicklung mit Java 13 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 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 14 Java ME: MIDlet-Lebenszyklus ● MIDlets werden wie Applets von der Umgebung gesteuert Konstruktor Paused destroyApp() notifyDestroyed() startApp() pauseApp() notifyPaused() Destroyed 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java Active destroyApp() notifyDestroyed() 15 Java ME: 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 protected void pauseApp() { Application Management Management System System } (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.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 16 Java ME: Entwicklungsumgebung ● Zum Bauen von Midlets benutzt man das … Java ME SDK (aktuell 8.1) – Demo-Applikationen – Emulator – Alle sonstigen Werkzeuge 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 17 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. keine Reflection Entwickler müssen sich mit anderen Bibliotheken anfreunden 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 18 Inhalt ● Motivation ● Java Micro Edition ● Java Card ● Alternativen ● – Android – .NET Micro/Compact Framework Zusammenfassung 06.07.2016 SuS: 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 ● – Enthalten Universalprozessor ● – 8-32 Bit, 3,5-5 MHz Extrem wenig Speicher ● ● ● ➔ Serielle Schnittstelle, Standardprotokoll 16-32 KB ROM 0,5-1 KB RAM 8-16 KB EEPROM Vcc Reset Clock RFU Definitiv zu klein für Java ME! 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java C1 C5 C2 C6 C3 C7 C4 C8 Ground Vpp I/O RFU 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.07.2016 SuS: 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.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 22 Java Card: Applets … ● ● sind persistente Zustandsautomaten, die auf Nachrichten des Lesegeräts reagieren haben (mindestens) folgende Methoden: – install ● – select ● – Das Lesegerät spricht das Applet an process ● – Erzeugung und Registrierung der Applet-Instanz Interpretation der Nachrichten (APDUs) vom Lesegerät deselect ● 06.07.2016 Das Lesegerät beendet die Kommunikation mit dem Applet SuS: 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.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 24 Inhalt ● Motivation ● Java 2 Micro Edition ● Java Card ● Alternativen ● – Android – .NET Micro/Compact Framework Zusammenfassung 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 25 Android ● Open Handset Alliance (primär Google), 2007 – ● ● Vision: “… accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience.” Infrastruktursoftware-Plattform für Smartphones – ● T-Mobile, Motorola, Samsung, ... Open Source Diverse Produkte heute verfügbar 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 26 Android: Architektur ● 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. Linux und Java – aber anders … 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 27 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 ● ● Java-Bytecode lässt sich nicht (direkt) ausführen Ein Übersetzungschritt ist erforderlich Heute: Trace-basierter JIT-Compiler 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? 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 28 Android: Größen (statisch) ● ● ● common system libraries – (U) 21 445 320 — 100% – (J) 10 662 048 — 50% – (D) 10 311 972 — 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) 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% 06.07.2016 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 29 SuS: 06.3 Anwendungsentwicklung mit Java Android: Größen (dynamisch) Quelle: A JIT Compiler for Android’s Dalvik VM Ben Cheng, Bill Buzbee, May 2010 ● JIT arbeitet Trace-basiert – – 06.07.2016 Übersetzung auf Ebene von Basisblöcken (statt ganzen Prozeduren) Ein Translation Cache pro Prozess (VM-Instanz) ● Trade-off zwischen Performance und Speicherbedarf akzeptabel SuS: 06.3 Anwendungsentwicklung mit Java 30 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 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 31 Android: ART (2) ● Partielle Code-Spezialisierung in JIT-Compiler – nicht bei ART Basierend Basierendauf aufder der Ausführungshäufigkeit Ausführungshäufigkeitvon von Funktionen mit bestimmten Funktionen mit bestimmten Parametern Parametern(ermittelt (ermitteltvom vom Trace-JIT) werden Trace-JIT) werden Funktionen Funktionenspezialisiert. spezialisiert. Entsprechende EntsprechendeAufrufe Aufrufe werden werdenumgeleitet. umgeleitet. int 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; } myfunc(7,5,2) int myfunc(int par1, int par2, int par3) { int r = 47; int i = 35; while (--i) r += i + i; return r; } 06.07.2016 myfunc(2,2,12) int myfunc(int par1, int par2, int par3) { return 16; } Quelle: c't 13/2015 „Endlich kompiliert“ SuS: 06.3 Anwendungsentwicklung mit Java 32 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) ● – 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 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 33 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 ● 06.07.2016 Übersetzung zum Installationszeitpunkt bei ART SuS: 06.3 Anwendungsentwicklung mit Java 34 .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 – Anwendungsentwicklung in MS Visual Studio – Diverse Bibliotheken ● ● ➔ Quelle: msdn.microsoft.com 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) 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 35 Inhalt ● Motivation ● Java Micro Edition ● Java Card ● Alternativen ● – Android – .NET Micro/Compact Framework Zusammenfassung 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 36 Zusammenfassung ● Java-Umgebungen bilden eine Produktlinie – ● Bei den kleineren Varianten gibt es Einschränkungen – ● Skalierbarkeit von 8-Bit-Chipkarten bis 64-Bit-Serversysteme 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 06.07.2016 SuS: 06.3 Anwendungsentwicklung mit Java 37 Literatur [1] [2] 06.07.2016 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. SuS: 06.3 Anwendungsentwicklung mit Java 38
