Consumer und Enterprise

Java-Anwendungen überall

Deutlich spürbar war diesmal der Trend in Richtung Consumer-Elektronik. Vom einfachen PDA über die Set-Top-Box bis hin zum NC reichte das Spektrum der vorgestellten

Clients. Kaum ein Endgerät, welches sich nicht für Java eignen würde. Oft arbeiten die Devices oder "Informa-tion Appliances" als Netzwerk-Clients (wireless), so daß Java sowohl auf der Client als auch der Serverseite zum Einsatz kommen kann. Für Scott McNealy ist klar: "Wenn ein Gerät vernetzt ist, dann gehört da auch eine Java Virtual Machine drauf. Am besten sollten die Hersteller gleich noch einen Kartenleser einplanen, damit die Kunden die Javacard-Sicherheit nutzen können".

Da man wohl nicht davon ausgeht, daß Microsoft sich der Thematik aktiv annimmt, portiert derzeit Sun selbst Personal-Java auf die CE-Plattform. Drei neue API-Sets (Java-TV, Auto-Java und Java-Phone), die im dritten Quartal diesen Jahres zu erwarten sind, sollen den potentiellen Markt für Produkte auf Java-Basis deutlich erweitern und den Programmierern mit den jeweils spezifischen Erweiterungen die Arbeit erleichtern.

Gerade die Flut unterschiedlicher Mikrocontrollerfamilien und der entsprechenden Systemumgebungen könnte dabei die wichtigste Rolle für eine von vielen herbeigesehnte Kehrtwende in Richtung der universellen Programmierumgebung Java spielen. Der Kostendruck im Embedded-Markt zwingt die Hersteller dazu, die Mikrocontrollerfamilien projektbezogen zu wechseln. Dies führt dazu, daß sich die Programmierer immer wieder in ungewohnten Umgebungen zurechtfinden müssen. Dies führt zu unnötigen und kostenintensiven Verzögerungen. Eine auf Java basierende Alternative könnte zu einer spürbaren Beruhigung führen und zudem den Anbietern der Entwicklungstools eine breitere und damit lukrativere Kundenbasis verschaffen.

Zu den Java-Features, die neben der universellen Programmierumgebung für Java sprechen, gehört unter anderem die Möglichkeit, alte Codeteile mit Hilfe der "Garbage Collection" zu löschen und durch neue Routinen zu ersetzen, die der Anwender über Funk, IrDa, Diskette oder Kabel auf das Endgerät laden kann. Diese sogenannten dynamischen Applets vereinfachen den Support nach dem Kauf und lassen sich zudem als einfache Möglichkeit nutzen, dem Kunden nach dem Kauf zusätzliche Optionen anbieten zu können. Das Java-Sicherheitssystem sorgt dabei für die gesicherte Übertragung der Routinen.

Neben den bereits erwähnten spezifischen API-Sets veröffentlichte Sun zur Javaone das Draft-Papier zur Embedded-Java-Plattform. Ein typisches Zielsystem für diese Plattform kommt mit weniger als 512 KByte ROM aus und nutzt ein Echtzeitbetriebssystem auf welches die Java-Umgebung aufgesetzt wird. Embedded-Java erlaubt dem Programmierer, auf unnötige Komponenten in der Java-Runtime-Umgebung zu verzichten ohne die Kompatibilität zu verlieren.

Für Unruhe sorgte in diesem Zusammenhang die Ankündigung von HP, eine eigene Java Virtual Machine (VM) anzubieten. Ausgehend von der offen zugänglichen Java-Spezifikation entwickele man eine eigene Variante, die Interessenten lizenzieren können. Erster Lizenznehmer war ausgerechnet Microsoft - ein Indiz für viele Beobachter, die in der neuen Allianz HP-Microsoft eine Schwächung der gemeinsamen Java-Entwicklung mit dem Hauptgedanken "Write once, run everywhere" sehen. Dr. Alan Baratz, President Javasoft, sieht für den Fall, daß HP alle Bestimmungen der Java-Lizenz einhält, kein Problem. Scheinbar will HP aber den speziell für Embedded-Applikationen optimierten Port ohne Abstract Window Toolkit (AWT) ausliefern. Für Baratz wäre dies ein Bruch der Bestimmungen. Scott McNealy bezog hierzu deutlich Stellung: "Java-Subsets lassen wir nicht zu - es wird keine Clones geben."

Microsoft selbst mußte am ersten Tag der Javaone einen herben Rückschlag hinnehmen. Nachdem der Internet Explorer 4.0 Ende September des letzten Jahres verfügbar war, stellte sich schnell heraus, daß dieser nicht in allen Belangen der Java-Spezifikation folgt und die JDK-Testsuite nicht fehlerfrei durchläuft. Unter anderem unterstützt die Microsoft-VM die als "Supplemental Java Classes" eingestuften RMI-Klassen (Remote Method Invocation) sowie das "Java Native Interface" (JNI) nicht. Beide müssen nicht Teil der ausgelieferten Java-Lösung sein, aber dem Kunden muß der Zugang zu entsprechenden Bibliotheken offenstehen. Die Testsuite findet zudem Fehler in den Public-Klassen, die auf Modifikationen beruhen. Sun klagte Anfang Oktober gegen Microsoft auf Einhaltung der Lizenzbedingungen und forderte für die Zwischenzeit, daß Microsoft auf das Java-Logo verzichtet.