Das Dokument behandelt die Herausforderungen und Entwicklungen im Bereich von Java auf mobilen Linux-Geräten, insbesondere hinsichtlich der Integration freier Java-Stacks und der Portierung auf Embedded-Systeme. Es wird auf verschiedene Implementierungen und Tools eingegangen, wie Jalimo, das eine vollständige, freie Java-Umgebung anstrebt, sowie auf Build-Strategien und Frameworks für mobile Anwendungen. Zudem werden die bestehenden Probleme, Fortschritte und die Rolle der Community bei der Weiterentwicklung dieser Technologien thematisiert.

1. Java-Linux-Mobile Plattform

2. Status Zuwachs an kleinen mobilen Linux Endgeräten Java auf mobilen Endgeräten Classpath & co sind 'erwachsen' dennoch! Freies Java auf Linux-Embedded ist kaum im Einsatz.

3. Java embedded? Was ist Java? J2ME CLDC J2ME CDC J2ME CDC + AGUI (JSR 209) J2SE Nur zertifizierte Plattformen (JVMs+Klassenbibliothek) dürfen sich 'Java' nennen. Die alternativen, freien JVMs sind nicht zertifiziert

4. Java und Java-like Implementierungen Sun J2SE – (GPL und proprietär) Sun J2ME PhoneME (GPL) J2ME IBM J9 (proprietär) Gnu Classpath (GPL) mit verschiedenen JVMs cacaojvm (GPL) jamvm (GPL) kaffe (GPL) ... Aonix, Perc (proprietär) Aicas, JamaicaVM (proprietär) ... } Realtime fähig

5. Wie immer – die GUI machts! Außer J2ME CLDC ist alles weitestgehend >= Java 1.3. Prägnant: Die unterschiedlichen GUI Ansätze. MIDP 2.0 (minimal) AWT (kleine Featuremenge) Swing (Performance Probleme) SWT (mit GTK peer: Viele Abhängigkeiten) SWT (mit QT peer: proprietär) Weitere Möglichkeiten Java-gnome escher (pure java X library) jsdl (java sdl bindings)

6. Pocket-Size Linux Distributionen Familiar (OpenEmbedded, ipkg) Ångström (OpenEmbedded, ipkg) Maemo (Scratchbox, apt, dpkg) OpenMoko (OpenEmbedded, ipkg) Environments Opie (Framebuffer/QT embedded) GPE (Xserver/GTK) Maemo (Xserver/GTK + Hildon + Osso) OpenMoko (Xserver/GTK + libmokoui + libmokocore)

7. Java @ Pocket-Size Linux Meist sporadisch: z.B. jamvm und altes gnu classpath Selten aktualisiert Kein Konzept für Packaging und weitere Integration GUI: Meist AWT (mit gtk peer) OpenEmbedded: jamvm 1.4.2/classpath 0.90 Maemo: jamvm 1.4.2/classpath 0.91 (ohne 'hildonizing') sun PhoneME (als tar.gz, ohne gui) JaLiMo

8. Welche Probleme gibt es? Bei der Java-Portierung Build Prozess ist meist etwas anders Abhängigkeiten für die GUI Fehlende Abstimmung auf embedded Bereich Größe & Modularisierung Startup-Geschwindigkeit Bei der Entwicklung Embedded Java ist etwas anderes Fehlende Integration in die Umgebungen Packaging + Dependency Management Fehlende Abhängigkeiten und Bindings Schlechte Framework Unterstützung

9. JaLiMo JaLiMo ist eine Initiative um einen vollständigen freien Java-Stack für mobile Linux Endgeräte aufzubauen. Im Vordergrund steht die Integration und Ergänzung existierender Projekte. "Java-like environment for mobile Linux devices" Hauptaufgabe sind die Probleme nach der Portierung der JVM!

10. JaLiMo - Wer? Gesponsort von Tarent GmbH Sebastian Mancke Robert Schuster (Gnu Classpath) Fabian Köster Unterstützt durch Christian Thalinger (cacaojvm.org) Roman Kennke (Gnu Classpath, escher) Guillaume Legris (MIDPath) Andrew Cowie (java-gnome) ...

11. JaLiMo - Was? Integration Integration GUI Runtime Build Plattform CACAO JVM JamVM GNU Classpath phoneME MIDPath Swing/escher java-gnome SWT maven packaging plugin OpenEmbedded integration mvn2deb libjalimo-core libopenmoko libmaemo maemo ...?... openmoko

12. Build Strategien - Cross Compiling Cross Toolchain (gcc, ld, .. für arm) Rootstrap setzen von: PATH, CC, LD, AR, PKG_CONFIG_PATH wrapper für: dpkg-architecture und pkg-config Vorteile: Die Host Tools (z.B. javac, javah, jar) stehen zur Verfügung. Verwendung zusammen mit dpkg-buildpackage Probleme Pflege des Rootstrap Fehleranfällig durch fehlendes chroot

13. Build Strategien - Scratchbox Auf Qemu basierender Emulator Mit Toolchain und Rootstrap integriert Vorteile: Direkte Nachbildung des Zielsystems Kein Cross Compiling mehr Probleme Keine Unterstützung spezieller Build Tools (z.B. javac, javah, ..) Java binaries (z.B. jamvm oder cacao) funktionieren nicht in der scratchbox

14. Build Strategien - maven2 Etablierte Java Build Umgebung Vorteile Management von dependencies Standardisierter Build Prozess Plugin Architektur Nachteile Sehr Java zentriert Schlechte Unterstützung für JNI und Cross Compiling Kein Packaging Konzept

15. maven packaging plugin Packaging IzPack installer (für Desktop) .deb (für Desktop und embedded) .ipkg (geplant) Generierung von Startscripten Orientierung an debian guidelines Umsetzung der maven Abhängigkeiten auf debian Abhängigkeiten Von tarent (Robert Schuster) entwickeltes maven Plugin zur Paketierung von Projekten -- unter (GPL) frei gegeben.

16. maven packaging plugin Java package fur maemo in 5 min! .. code schreiben und pom.xml anpassen .. .. fertig ist das .deb archive! mvn archetype:create \ -DarchetypeGroupId=org.jalimo.archetype \ -DarchetypeArtifactId=gtkapp -DarchetypeVersion=0.1.0-SNAPSHOT \ -DremoteRepositories=http://www.jalimo.org/maven \ -DgroupId=<your project group id> -DartifactId=<your artifact id> mvn -Dmaven.test.skip=true pkg:deb

17. maven mit JNI code Normales maven packaging Projekt + Makefile Ablauf: mvn pkg:deb Kompilieren der Java Klassen Generieren der header files mit javah Kompilieren des C-codes in der scratchbox über /scratchbox/login <scriptfile> Einsammeln der Binaries Generieren des .deb Archives Viele Projekte bestehen aus java und C code } } } Host Host Emulator Beispiel: java-gnome

18. Java-gnome Java-gnome ist ein bereits 9 Jahre bestehendes Projekt Version 2 hat eine recht hohe API-Abdeckung, jedoch zu viele Probleme. Seit 1,5 Jahren: rewrite java-gnome4 Sauberes Design Leichtgewichtig Geringe API-Abdeckung Kommt leider langsam vorwärts Aber: gutes Konzept

19. Java-gnome - Konzept Code Generierung der JNI Schicht Aus den GTK Header Files werden Objekt Definitionen erstellt. Pro Gtk 'Klasse' wird eine C und ein Java Datei generiert, die den gesamten JNI-Code enthält. Java Sichtbarkeiten dieser Schicht sind auf 'package' beschränkt. In einer sauberen API Schicht erfolgt die Umsetzung des prozeduralen Codes in eine objekt-orientierte API. Die pseudo-Klassenstruktur von GTK wird dabei sauber in Java abgebildet. Das Vorgehen und der Codegenerator eignen sich evtl. auch für andere Bibliotheken: z.B. Hildon oder libopenmoko.

20. Java-gnome Warum von Java-gnome Performant und leichtgewichtig Nahtlose Integration möglich Unterstützung durch Glade2 GUI Builder Einfache, schöne API

21. Java-gnome - Abdeckung Im Upstream Projekt sehr gering: Window, Widget, Button, Label, Hbox, VBox Prototypische Erweiterung an zwei Abenden um: Entry TextView, TextBuffer ToggleButton CheckButton ComboBox MenuBar, Menu, MenuItem ScrolledWindow Frame Notebook HSeparator, VSeparator Image Offensichtlich: gutes Konzept!

22. libmaemo Erweiterungen der java-gnome Komponenten mit Bindings zum Hildon Framework. Nötige Schritte: Wrapper für HildonWindow und HildonProgram (existieren schon) Erweiterte Widgets des Hildon Frameworks Bindings für Status Bar Plugins Wrapper für die libosso Nachrichten Kommunikation zwischen den Applikationen Evtl. über bestehendes Projekt java-dbus möglich

23. MIDPath MIDPath ist eine MIDP2 Implementierung auf Basis des MIDP codes der Sun PhoneME. Im Gegensatz zur PhoneME läuft MIDPath auf Java SE sowie auf Java ME CLDC. Damit kann es out of the box mit Kaffe, Cacao, JamVM oder anderen JVMs verwendet werden. Guillaume Legris hat für JaLiMo ein GTK Backend geschrieben, was wir an das Maemo Input Framework anpassen konnten.

24. MIDPath - Architektur Durch unterschiedliche Backends ist MIDPath recht portabel. Für den Einsatz auf kleinen Geräten gibt es eine Variante, die mit der Cacao CLDC Version aus kommt. MIDPATH Java ME CLDC AWT SWT JavaSound SDL X11 ALSA Cacao JamVM Kaffe Cacao CLDC GNU Classpath JVMs Standard Libraries Backends Core GTK

25. MIDPath - Status Status: Recht Stabil APIs: JSR-118 + FileConnection (JSR-75) Fehlend: SSL, UDP, tone playing OGG/MP3 Unterstützung Bald: Audio streaming support Midlet Verwaltung für Maemo Zukunft: Weitere Java ME JSRs hinzufügen

26. Swing/Escher Swing/AWT Support von GNU Classpath in maemo hängt an der gtk Version. Alternative Pure Java X library: Escher Classpath hat unterschiedliche peers für AWT und Swing Swing/Escher läuft auf maemo, ist aber noch nicht fertig: Probleme im Fenster Handling Repainting Soft Tastatur Input Look and Feel Customizing

27. Swing/Escher - Maemo Input Problematik Soft Keyboard löst keine X Key-Events aus Text orientiert Undokumentierte Xmessages, die über das Hildon/GTK Input Framework in GTK umgesetzt werden. TODO: Generieren von XMessages an Softkeyboard (raise/lower) Empfangen von Messages, umwandeln in AWT Key Events

28. lib-JaLiMo Zielausrichtung JaLiMo steht am Projekt Anfang Vollständigkeit einer 1.0 geplant für Ende 2008 Bisher: Fokus auf Basis Plattform Hauptsächlich jedoch: Applikationsframework Erstellen von mobilen Applikationen zur Umsetzung von End-to-End Business Prozessen.

29. lib-JaLiMo Konzepte Messaging Asynchrones Messaging als Grundbaustein der Applikationen Anbindung verschiedener Quellen über Konnektoren z.B. SOAP/HTTP, XMPP, RMI, dbus Applikation MessageBroker

30. lib-JaLiMo Konzepte Data-Binding Bindung von Daten und View über Nachrichten aneinander Deklarative Verknüpfung, ohne gegenseitiges Referenzieren der einzelnen Objekte Bietet stärkere Entkoppelung als MVC-Paradigma Action Framework Konsequenter Einsatz des Command Patterns in GUI Applikationen Alle Aktionen werden als Action definiert und können an unterschiedlichen Stellen verwendet werden.

31. lib-JaLiMo Konzepte GUI Templating Erstellung von Teilen der GUI durch Beschreibungssprachen z.B. HTML embedded in Swing Glade für Java-Gnome JSP oder Velocity für Web Verbindung von GUI und Applikation über Actions und Bindings Ziel: Leichteres Wiederverwenden von Applikationen in unterschiedlichen Kontexten Rapid Prototyping Trennung von Gestaltung und Programmierung

32. JaLiMo - Robot Aktion Warum? Zur Verdeutlichung, wie einfach sich offene Standard-Komponenten für komplexe Architekturen eignen. Autonome Java Steuereinheit Java-gnome GUI Asynchrone Kommunikation über XMPP Entwicklungsaufwand ~ 1 Woche

33. Jazelle DBX (Direct Bytecode eXecution) Das N770 und das N800 besitzen die proprietäre Jazelle Erweiterung im Prozessor. DBX ist ein zusätzlicher instruction modus des arm Prozessors. Nach einem sog. branch to java kann bytecode nativ ausgeführt werden. 123 Bytecodes werden dabei direkt unterstützt. Für die übrigen wird ein Software Interrupt ausgelöst. Leider hält Arm die Spezifikation zurück!!! Wäre es möglich sie trotzdem zu nutzen?

35. Jazelle DBX (Direct Bytecode eXecution) In den DBX-Modus zu wechseln scheint kein Problem zu sein Mit dem db lässt sich nachvollziehen, dass das Programm immer nach dem letzten bekannten bytecode abstürzt. Alle vorangegangenen müssen also abgearbeitet worden sein. Nach einem der unbehandelten Bytecodes steht der program counter auf 0x11000. Dies scheint der Zustand nach dem interrupt zu sein. Offene Fragen: Wie muss der entsprechende Interrupt handler aussehen? Wie erfolgt eine Parameterübergabe/Parameterrückgabe?

36. JaLiMo Ressourcen www.jalimo.org Bald zusätzlich: www.elvolvis.org Gforge infrastruktur Öffentliches svn Mailinglisten Bessere Verwaltung von Einzelprojekten Ansonsten: [email_address]