Login
Newsletter
Werbung

Thema: Keine Linux-Applikationen für Motorola Linux-Handy

1 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Jan Brinkhaus am So, 23. März 2003 um 20:26 #
Jungs... ich weiß nicht, wovon ihr hier redet, wenn Ihr meint,

1. Java sei langsam und könne auf auf Handys ja garnicht laufen
2. Java sei ungleich Java / das gäbe ja eh ein "Motorola-Java"

ad 1) Selbstverständlich ist ein interpretierter Code relativ langsam im Vergleich zu nativen Code. Meinen Erfahrungen aus dem Embedded-Bereich zufolge allerdings reicht es für vieles aus!? Auf einem Handy soll ja gerade nicht ein Bildschirm mit vielen Bedienelementen, einer aufwendigen Eventverwaltung,... dargestellt werden. Für viele Zwecke reicht Java hier aus.

Wirklich sinnvoll ist es freilich nicht, zwischen Programme und System einen abstrahierenden, auch noch interpretierenden, Layer zu packen. Aaaaber:

ad 2) Java ist seit einiger Zeit durchaus zumindest "etwa gleich" Java. So Späße, wie Microsoft sie mit seiner VM geleistet hat, sind seit geraumer Zeit nicht mehr möglich. Wer sich mit dem Markennamen "Java" schmücken möchte, muss ein Kompatibilitätstestkit kaufen (50000$ !!) und erfolgreich durchlaufen lassen.

Von AWT oder Swing oder komischen VMs ist auf dem Handy auch keine Rede. Es gibt zum einen mit der J2ME/CLDC-Umgebung ein detailliertes Set von Definitionen, wie die VM auszusehen hat, was die Basisklassen sind und was sie zu tun haben. Zum anderen sind die hier aufgesetzten Erweiterungen z.B. das "MIDP", ein Set von APIs, welches Schnittstellen von portablen Endgeräten definiert.

Sicherlich haben Handyschirme immernoch verschiedene Auflösungen und Tastaturen verschiedene Anordnungen von bestimmten Steuerelementen. Aber so etwa in der Liga liegen die Unterschiede zwischen den Java-Implementierungen.

Als Grundlage der VM selbst wird oft der von Sun frigegebene Code der KVM genommen. Das ist eine virtuelle Maschine, die kompiliert (x86) etwa auf 100KB kommt. Sun liefert die VM im Quellcode aus. Wer damit eigene Produkte baut, muss allerdings das oben beschriebene Testtoolkit kaufen, um die Kompatibilität zum Java-Standard zu beweisen. Ferner sind Stückkosten fällig. Ob man nun die grundsätzlich oft ähnliche Codebasis oder das Testkit als Hauptgrund sieht: die VMs bieten oft tatsächlich exakt definierte Schnittstellen und Verhaltensweisen.

-->

Und genau dann macht der Abstraktionslayer zum OS wieder Sinn... der an sich performancekillende Javalayer standartisiert die Programmierung auf den Endgeräten und bietet gleichzeitig ein durchdachtes Sicherheitskonzept.


[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung