Kommentar: Vom "Feature-Phone" zum "Internet der Dinge" - die Renaissance von Java ME

Wir schreiben das Jahr 2013, und Java MEist in aller Munde – zumindest, wenn man die Meinungsmacher der diesjährigen, nun zu Ende gegangenen JavaOne in San Francisco als Trendbarometer heranzieht. Was ist passiert? Wie kommt es, dass die Java Micro Edition wieder hoffähig zu sein scheint?

Um es gleich vorwegzunehmen: Java ME auf dem Mobile-Gerät ist auch weiterhin tot – und das bleibt so. Zumindest für Smartphones, die bei uns im deutschsprachigem Raum im Nutzerfokus stehen. Hier dominieren klar iOS und Android den Markt. Auf den sogenannten Feature Phones dagegen, also den Highend-Geräten der Vor-Smartphone-Ära, ist Java ME nach wie vor stark vertreten. Java ME erreicht in Summe über alle Mobile Devices weltweit immerhin noch knapp 10 Prozent Marktanteil und ist damit – dank Lizenzmodell – weiterhin eine Cashcow. Die Lizenzierung ist übrigens auch ein wesentlicher Grund dafür, dass Java ME 2006 im Zuge der allgemeinen Öffnung von Java nicht Open Source wurde.

Bereits letztes Jahr wurde jedoch deutlich, dass Oracle mit Java ME zukünftig den stark wachsenden Markt der Embedded Devices und – genauer – das Internet of Things angehen möchte. Analysten sagen für diesen Sektor einen Wachstumsmarkt von zwei- bis dreistelligen Milliardenbeträgen in den kommenden fünf Jahren voraus. Oracle tut also gut daran, sich auf diesem Markt zu positionieren.

Die Herausforderungen allerdings, diesen wachsenden Markt zu bedienen, sind enorm. Kommunikation zwischen unterschiedlichsten Protokollen, End-to-End Security, Software-Provisionierung und Lifecycle-Management über verschiedenste Geräte hinweg und Unmengen an nicht qualifizierten Daten, die durch die vielen Geräte erzeugt und serverseitig verarbeitet beziehungsweise ausgewertet werden wollen, sind nur einige davon.

Wie passen hier Java und insbesondere Java ME ins Bild? Das bisher präferierte Programmiermodell auf Basis von Assembler oder C/C++ inklusive proprietärer Kommunikationsprotokolle führt mittelfristig ins Chaos und ist schon heute kaum noch beherrschbar. Wiederverwendung einmal geschaffener Entwicklungen über Gerätegrenzen hinweg ist nahezu ausgeschlossen. Und ganz nebenbei fehlt es auch an der ausreichenden Anzahl qualifizierter Entwickler, insbesondere im Assembler-Umfeld.

Genau hier liegt die große Chance von Java ME. Neben einer verhältnismäßig sichereren und vor allem stabilen Laufzeitumgebung, ein Muss bei Geräten, die häufig nur schwer oder gar nicht zugänglich sind, kann auf eine extrem große Entwickler-Gemeinde – die Java-Community – zurückgegriffen werden.

Dank vollständig überarbeiteter Ausrichtung von Java ME 8 ist die Plattform zukünftig deutlich stärker an Java SE angelehnt als bisher. Vereinfacht gesprochen bilden die zugehörigen JSRs 360 (Connected Limited Decice Configuration 8) und 361 (Java ME Embedded Profile) ein direktes Subset von Java SE ab. Das gilt sowohl für die zu verwendenden Sprachfeatures als auch für APIs und VM. Das Rad ist somit nicht für jedes Gerät neu zu erfinden. Einmal entwickelter Code kann stattdessen plattformübergreifend, also vom Embedded Device bis zum Server, eingesetzt werden. Gleiches gilt für den Entwickler. Ein echter Wettbewerbsvorteil bei den heutigen Anforderungen an Time-to-Market.

Um dabei trotzdem den stark unterschiedlichen Anforderungen der verschiedensten Zielplattformen gerecht zu werden, lässt sich bei Java ME 8 aus drei unterschiedlich umfangreichen Profiles – Minimal, Standard und Full – auswählen. Eine weitere Optimierung kann durch die Verwendung der optionalen CLDC-Compact-Spezifikation anstelle von CLDC erreicht werden – Projekt Jigsaw für ein Java-Modulsystem und Java 9 lassen grüßen.

Das vorhandene Chaos proprietärer Lösungen am Markt sowie die voraussehbaren Wachstumsraten der Embedded Devices stellen eine echte Chance für Java dar. Dank zuverlässiger und sicherer Plattform sowie stark modularisierter und zukünftig direkt aufeinander aufbauender Struktur von Java ME und Java SE können sowohl Code als auch Entwickler übergreifend eingesetzt werden.

Was allerdings nach wie vor gänzlich fehlt, ist ein auf die aufkommenden Herausforderungen zugeschnittenes Framework, dass da ansetzt, wo die APIs aufhören und sich der übergreifenden Infrastrukturaufgaben wie Zugriffsberechtigungen und Provisionierung annimmt. Die Wahrscheinlichkeit, dass ein solches Framework herstellerübergreifend und gemeinsam [Update, 30.09.13: innerhalb des JCP] spezifiziert werden wird, ist aufgrund des damit verbundenen Zeitaufwands und des zugleich real existierenden Marktdrucks eher gering. Wer als Erstes mit einer sinnvollen Lösung am Markt erscheint, hat große Chancen, einen De-facto-Standard zu etablieren. (ane)