Heute habe ich mir die
MSA 2 ist aufgeteilt in 3 Plattformen: Entry, Standard und Advanced. Die drei Plattformen bauen aufeinander auf und umfassen jeweils eine Menge von JSRs, die für den mobilen Bereich gedacht sind. Insgesamt sind es 27 JSRs in der Advanced Plattform. Das Problem: auf jeder Plattform gibt es wiederum Conditionally Mandatory APIs – nicht zwingend vorgeschriebene Schnittstellen. Beispielsweise ist Bluetooth in der Entry Plattform Conditionally Mandatory. Innerhalb des Bluetooth JSR 82 ist das OBEX API optional. Wenn schon an der Bluetoothschnittstelle gespart werden muss, dann kann in solchen Geräten auch gleich auf eine Java Umgebung verzichtet werden. Besonders sinnlos sind solche optionalen Sub-APIs bei den Advanced Multimedia Supplements Schnittstellen. Niemand wird wirklich 3D-Sounds in seinen Programmen einsetzen, wenn ein solches API optional ist. Genauso gut kann dann darauf verzichtet werden.
Viel wichtiger als de API-Konsolidierung ist es den schrecklichen Zertifikatedschungel zu lichten. Es geht darum den Markt für kleine Applikationen durch freie oder semiprofessionelle Entwickler zu erobern. Da macht es keinen Sinn zig hunderte Dollar jährlich für Zertifikate auszugeben, um die wichtigsten Hersteller zu unterstützen. Der Java Verified Process ist unsinnig. Welcher Hobbyentwickler kann schon einen dreistelligen Dollarbetrag ausgeben, um seine Applikation für ein Handy-Modell (oder Modellfamilie) verifizieren zu lassen – bei hunderten infrage kommender Modelle? Jedes Update muss erneut verifiziert werden. Schlägt eine Verifizierung fehl: Pechgehabt, die Kohle ist weg. Bei 2 Updates pro Jahr plus Zertifikat sind da schon mal schnell 500-700 Dollar fällig. Bei den wichtigsten Handy-Modellen kommt da schnell ein fünfstelliger Betrag zustande. Zum Vergleich: 100 Dollar bei Apple oder Microsoft. Wenn das Problem gelöst ist, dann kann das auch mit Java Mobile noch was werden. Vorher nicht.
