Interview mit Klaus Bergius, Senior Wireless Technologies Architect, Technology and Archtitecture Office, Sun Microsystems GmbH auf der JAX 2003

"Java ist im mobilen Telefonmarkt bislang eine sehr große Erfolgs-Story"

Kay Glahn

Klaus Bergius hat etwa 20 Jahre Berufserfahrung in der EDV-Branche bei Hard- und Software Herstellern, Rechenzentrum und ISV-Umfeld als Dozent, Systemanalytiker und Berater. Er ist seit 1993 in verschiedenen (Software-lastigen) Positionen bei Sun Microsystems in München tätig. Seit 3 Jahren als Senior Architect und Technologist in den Bereichen Mobility, Wireless und Infrastruktur Software im Technology and Architecture Office.

psenv::pushli(); $li=0;$row->listindex=0;eval($_oclass[„interview“]); psenv::popli(); ?>

Klaus Bergius: Die Zahlen, auf die wir uns stützen, werden von Marktforschungsunternehmen erfasst und zeigen uns, dass zur Jahreswende 2002/2003 bereits über 100 Millionen Java Enabled Phones im Weltmarkt waren. Das entspricht unseren Erwartungen und wir liegen damit ganz gut im Plan. Nach verschiedenen Quellen machen Java Phones heute ca. 15 bis 20 Prozent aller Mobiltelefone aus. Auch wenn in der weltweiten Betrachtung viele Modelle für uns in Europa nicht relevant sind (aufgrund von technischen Inkompatibilitäten der Netze oder auch spezifischen Erweiterungen durch die Netzprovider z.B. im asiatischen Raum), hat das zu einer enormen Anzahl von J2ME-Anwendungen geführt. Java im mobilen Telefonmarkt ist damit bislang eine sehr große Erfolgs-Story. Auch auf der Entwicklerseite spiegelt sich das wider. Wir zählen mehr als 3 Millionen Java-Entwickler.

psenv::pushli(); $li=1;$row->listindex=1;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Es ist zwar schwer zu sagen, wie viele davon exakt J2ME-Entwickler sind, aber allein gemessen an den Downloads für das J2ME Wireless Toolkit sind das über 300.000. Da natürlich viele mit Tools anderer Hersteller arbeiten, sind das also sicher mehr als 10 Prozent der Java-Entwicklergemeinde.

psenv::pushli(); $li=2;$row->listindex=2;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Die Standards betreffend verwendet der Großteil der Geräte auf dem Markt heute den MIDP 1.0-Standard. 1.0 setzt freilich der Entwicklung klare technische Grenzen, die allerdings mit MIDP 2.0 nun angehoben werden. Durch die Technik-Brille betrachtet wünscht man sich da immer mehr, als der Standard dann letztlich spezifiziert. Der Java Community Process ist aber ein demokratischer Prozess, in dem auch Sun nur eine Stimme hat und das führt dann eben oft dazu, dass wir auch unsere Wünsche und Vorstellungen nicht oder nicht in vollem Umfang durchsetzen können. Das trifft auch auf MIDP 2.0 zu, wo es anfänglich im Prozess mehr interessante Vorschläge gab, als letztlich im endgültigen Standard nun enthalten sind.

psenv::pushli(); $li=3;$row->listindex=3;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Also ich rechne damit, dass immer wenn es heißt: Ab diesem Sommer, dann erscheinen in den Läden “ für alle zu kaufen “ die Geräte meistens im August oder September, also im Frühherbst. Das wird auch hier voraussichtlich der Fall sein. Letzte Woche war ich beispielsweise auf der Symbian Expo in London und Symbian hat gerade das neue OS 7.0s vorgestellt. Das ist inzwischen auch schon an die Lizenznehmer von Symbian ausgeliefert und enthält auch MIDP 2.0. Es ist also nur noch eine Frage der Zeit. Kein Hersteller hat bisher öffentlich gesagt, wann ein MIDP 2.0-Gerät herauskommt. Und wenn ich es wüsste, dann dürfte ich es auch nicht sagen.

psenv::pushli(); $li=4;$row->listindex=4;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Na ja, das kommt ein bisschen darauf an, wie lange man erwartet, dass die Entwicklung dauert. Wenn ich davon ausgehe, dass ich drei bis vier Monate brauche, bis ich die Anwendung fertig habe, dann kann ich mir schon überlegen, heute auf Basis der 2.0 Referenzimplementierung und des Toolkits für die Micro Edition für MIDP 2.0 zu entwickeln, weil es dann schon realistisch ist, dass man ab dem Frühherbst auch an die Entwicklergeräte von einzelnen Herstellern herankommen kann. Das wird sicherlich noch limitiert sein, ist aber letztlich genau das gleiche Spiel wie jedes Jahr. Aber es kommt sehr stark auf die Features an. Wenn ich heute ein Telefon habe, das ein Miniatur-Schwarzweiß-Display hat, dann werde ich darauf wahrscheinlich keine Spiele-Entwicklung machen und dann kann es sein, dass MIDP 1.0 völlig ausreicht. Wenn ich auf Features wie beispielsweise SSL angewiesen bin und das direkt in der Java-Implementierung nutzen will, dann muss ich 2.0 nehmen, das ist klar. Die interessanten Features aus meiner Sicht in 2.0 sind eben Security und auch der Push Support. Das heißt, dass ich erstmalig auch Anwendungen registrieren kann, die dann aufgerufen werden, wenn ein bestimmtes Push-Signal eintrifft. Das ist eine vereinfachte Form von dem, was wir uns ursprünglich vorgestellt hatten. In einzelnen Projekten haben wir auch mehr an solchen Features implementiert. Zum Beispiel die Parameterübergabe von MIDlet zu MIDlet und die MIME Type Registry für MIDlets im Telefon. Das gibt es in einzelnen Carrier-Netzen als spezifische Entwicklung. Es wäre natürlich schön gewesen, das in MIDP 2.0 generell zu haben.

psenv::pushli(); $li=5;$row->listindex=5;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Ja und Nein. Die MIDlets, die heute unter 1.0 laufen, laufen natürlich auch in 2.0, das heißt, ein MIDP 1.0 MIDlet ist damit aufwärtskompatibel zur MIDP 2.0 Plattform, allerdings mit der Einschränkung, dass es dort als so genanntes untrusted MIDlet läuft, es kann also nicht die erweiterten Security Features auf dem Telefon nutzen oder erhält die Freischaltung zusätzlicher APIs, die nur für trusted MIDlets erlaubt werden, nicht. 1.0 MIDlets laufen aber grundsätzlich auf einer 2.0-Plattform und damit ist die Aufwärtskompatibilität gewährleistet. Klar ist, so wie bisher auch, dass es herstellerspezifische Erweiterungen gegeben hat, um beispielsweise den Vibrationseffekt in einem Telefon anzusteuern oder ein eigenes Grafik-API zusätzlich zu implementieren. Das war ja bisher in 1.0 schon so. In 2.0 ist der Schritt vorwärts letztlich, dass nun Teile in Form der Gaming-Komponenten oder der erweiterten User Interface-Komponenten im Standard festgeschrieben werden. Ich glaube aber, es wird sich nie verhindern lassen, dass die Gerätehersteller trotzdem eigene Erweiterungen entwickeln, einfach auch weil es ein Differenzierungskriterium ist. Wenn ich als Hersteller ein Gerät habe, das besondere farbliche oder 3D-beschleunigte Fähigkeiten hat, dann will ich die natürlich auch an meine Java-Entwicklergemeinde und an die Anwender weitergeben. Wenn der Standard dann noch nicht da ist, dann ist das letztlich so immer noch der einzige Weg, so etwas auf den Markt zu bringen. Von unseren Java-Lizenznehmern wurde aber auch stets betont, dass solche Implementierungen nur Zwischenschritte sind und man letztlich immer den später verfügbaren allgemeinen Standard verwenden wolle. Im asiatischen Markt, der ja gerne als Negativ-Beispiel für die Fragmentation des Java-Standards angeführt wird, sind es auch eher die Netzprovider als die Gerätehersteller, die solche Vorgaben machen. Im europäischen Markt gibt es zwar auch solche Überlegungen, aber die Provider genau wie die Hersteller sind sich darüber im Klaren, dass ein sauberer Java-Standard besser für den Markt und den Kunden ist. Ich sehe schon, dass da ein Commitment da ist, den Standard rein zu halten.

psenv::pushli(); $li=6;$row->listindex=6;eval($_oclass[„interview“]); psenv::popli(); ?>

Bergius: Ja, ich habe auch immer ein komisches Gefühl, wenn man auf der einen Seite über Java Geschäftsanwendungen spricht, aber auf der anderen Seite eben heute mehrheitlich Telefone mit kleinen, nicht-farbigen Displays hat, die sich eher schlecht für seriöse Geschäftsanwendungen eignen. In diesem Segment ist natürlich ein Smartphone, das annähernd die Größe eines PDAs hat, viel besser positioniert. Allerdings darf man auch nicht immer nur auf Anwendungen schielen, die vom Notebook etwas verkleinert werden und damit auf einen PDA passen, das funktioniert ja so ohnehin nicht. In der Praxis bedürfen die Clients eines kompletten Redesigns, das von den Fähigkeiten und der Ergonomie des Endgerätes ausgeht. Es gibt daneben aber auch den Bereich, in dem man nur schnell beispielsweise Kontaktinformationen oder Bestellstatus, Auftragsinformation etc. in Kurzform abfragen will, und hier kann auch ein normales kleines Java-Telefon sehr gute Dienste bei der Anbindung an eine Firmenanwendung leisten. Das ist jedenfalls deutlich besser, als per WAP oder per SMS derartige Informationen abzufragen. Es ist ja auch eine Kostenfrage, ob man den Außendienstmitarbeitern allen ein teureres Smartphone zur Verfügung stellt oder die einfache Form auf dem ohnehin vorhandenen Java Phone realisiert. Vielleicht haben wir da auch alle während des vergangenen UMTS-Hypes die Erwartungen zu hoch geredet. Ich glaube das alte KISS-Prinzip (Keep It Short and Simple) sollte hier nach wie vor Entwicklungsprinzip sein, trotz farbiger Bildschirme und polyphoner Töne.

Übrigens macht der Markt für unternehmensorientierte mobile Anwendungen in Europa nur etwa 25 Prozent aus, der Consumer-Markt hingegen 75 Prozent. Das erklärt auch, warum viel mehr an Klingeltönen, Logos und Spielen verdient wird und Java als Spieleplattform im Mobiltelefon so attraktiv für die Entwicklung ist.

psenv::pushli(); $li=7;$row->listindex=7;eval($_oclass[„interview“]); psenv::popli(); ?>

psenv::pushli(); $li=8;$row->listindex=8;eval($_oclass[„interview“]); psenv::popli(); ?>

Geschrieben von
Kay Glahn
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.