Jalimo Slides Linuxtag2007

Java-Linux-Mobile Plattform

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.

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

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

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)

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)

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

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

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!

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)

...

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

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

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

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

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.

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

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

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

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.

Java-gnome

Warum von Java-gnome

Performant und leichtgewichtig

Nahtlose Integration möglich

Unterstützung durch Glade2 GUI Builder

Einfache, schöne API

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!

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

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.

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

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

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

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

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.

lib-JaLiMo Konzepte

Messaging

Asynchrones Messaging als Grundbaustein der Applikationen

Anbindung verschiedener Quellen über Konnektoren z.B. SOAP/HTTP, XMPP, RMI, dbus

Applikation MessageBroker

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.

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

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

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?

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.