Auch wenn es zum Leidwesen aller Interessierten von Apple selbst noch keine Release-Pläne oder Meinungsäußerung zur Veröffentlichung von Java 6 auf Mac OS X Leopard gibt, gibt es dennoch Hoffnung.
Landon Fuller hat sich des Java 6 für BSD angenommen und angefangen es auf Mac OS X zu portieren. Eine erste Developer Preview ist nun verfügbar. Bis auf den Sound und einige andere Dinge läuft die Version. Auch grafische UIs (Swing) werden Dank X11 zur Verfügung gestellt.
Die Seite von Landon Fuller gibt ausführliche Informationen dazu, wie das JDK 6 unter Mac OS X Leopard (er macht auch Angaben zu Tiger) zum Laufen gebracht werden kann.
Insgesamt eine erfreuliche Entwicklung, aber das sollte Apple nicht aus der Pflicht entlassen, ein eigenes, auf OS X optimiertes Java 6 (inklusive der grafischen UI-Bibliotheken) zu veröffentlichen, es besteht noch immer Hoffnung…
Update:
Mittlerweile gibt es bei Landon Fuller schon das Developer Preview Release 2 für Leopard und Tiger, sowohl als Source als auch als Binary.
Seit ich das Android SDK und das Eclipse Plugin für Android installiert habe, kommt es von Zeit zu Zeit zu einem Einfrieren von Keyboard und Trackpad auf meinem MacBook.
Bedingung ist lediglich, dass Eclipse mit dem Plugin gestartet wurde. Trackpad und Keyboard reagieren einfach nicht mehr, das einzige was hilft ist ein Reboot des Systems (die USB Maus geht glücklicherweise noch).
Das System ist ein MacBook Core 2 Duo, 2 GB RAM, OS X 10.5.1, Eclipse Europa.
Kennt jemand das Problem oder gar eine Lösung?
Update / Lösung:
Laut einem Eintrag in der Google Group ist das Problem mit dem neuesten SDK: android_sdk_darwin_m3-c22a gelöst.
Das Android SDK der Open Handset Alliance ist noch keine Woche erschienen, schon gibt es die ersten unabhängigen Ressourcen und Communities zu dem Thema.
Zwar sollte die offizielle Google Group die erste Anlaufstelle sein, aber einige der folgende Foren und Communities werden in Zukunft sicher auch gute Informationsressourcen zu dem Thema werden:
http://www.androidboards.com/
http://anddev.org/
http://androidcommunity.com/
http://www.androidev.com/
http://www.android-developers.de/
http://androidwiki.com/wiki/Main_Page
http://www.android-portal.com/
Update: Ich hatte an sich vor, obige Liste ständig zu erweitern. Aber momentan schießen die Android-Sites wie die Plize aus dem Boden, so dass man fast mal besser abwartet, welche Seiten sich durchsetzen werden.
Liest man oberflächlich die Spezifikationen zur Android-Plattform durch, sieht man sofort, dass die Anwendungen dafür in Java geschrieben werden.
Beim zweiten Blick muss man sich jedoch fragen, wird denn dort auch Java Bytecode ausgeführt? Die Frage kann man wohl mit einem Jain, wenn nicht sogar mit einem Nein beantworten. Jedenfalls wird Bytecode in einer virtuellen Maschine namens Dalvik ausgeführt. Und Javaprogramme, die etwa mit dem Eclipse-Plugin für Android entwickelt werden, werden mittels der dx Tools noch einmal in Dalvik-Bytecode übersetzt.
Dalvik ist eine virtuelle Maschine, wie Suns JVM oder die von .net, nur dass sie eben Google gehört. Möglich wird das dadurch, dass Google Android sich stark am Apache Projekt Harmony (einer Java SE unter Apache Lizenz) bedient und so gar nicht erst mit den Ansprüchen von Sun in Berührung kommt. Das ganze Vorgehen erinnert ein wenig an das Google Web Toolkit (GWT) auch dort schreibt man Javacode, der in diesem Fall dann allerdings in DHTML/Java-Script übersetzt wird.
Google verwendet bei Android Java vorwiegend als Programmiersprache weniger als Runtime. Für mobile Endgeräte unhandliche Dinge wurden beiseite gelassen (etwa Swing). Dafür schreibt man seine Oberflächen nun in einer deklarativen XML Syntax (XUL lässt grüßen). Die Klassenbibliotheken die Google mitliefert etwa für openGL, Bluetooth oder USB gehen auch deutlich über das Angebot von Java Mobile Edition (ME) hinaus und sind für Entwickler sicherlich interessant.
Die Sorge bei Sun um die Einheitlichkeit von Java ist jetzt groß. Auf der anderen Seite zielt Android nur auf den Markt der Mobile Devices und das, was Sun dort zu bieten hat, die Java ME ist alles andere als einheitlich. So bringt Google zwar keine Standard-Implementierung von Java an den Start, vereinheitlicht dafür aber wahrscheinlich mittelfristig die Java-Entwicklung auf mobilen Endgeräten, etwas, das Sun nie geschafft hat.
In einigen Blogs und Gruppen spricht man schon von Gava statt von Java
)
Heute hat die Open Handset Alliance unter der Führung von Google das SDK und entscheidende Details zur Architektur von Android veröffentlicht. Android ist die technische Basis, auf der 32 Hersteller von Mobiltelefonen, Netzbetreibern und anderen Firmen aus dem mobilen Markt eine gemeinsame Plattform erstellen, die dann mobile Endgeräte antreiben wird.
Die beste Nachricht zuerst: Die Entwicklungssprache der Wahl für Android, so der Codename für das Betriebssystem des sog. GPhones, ist Java. Eine spezielle von Google entwickelte JVM namens Dalvik übernimmt die Ausführung von Java-Bytecode. Im Hintergrund arbeitet ein Linux mit Kernel 2.6 als Betriebssystem. Zur Persistierung stehen neben dem Dateisystem auch eine SQLite Instanz zur Verfügung.
Google stellt neben dem SDK ein Eclipse-Plugin zur Entwicklung zur Verfügung und lobt $10.000.000 Preisgeld für innovative Android-Entwicklungen aus. Ein fulminanter Start, mehr kann man im Moment kaum sagen. Mit dieser Taktik zieht Google sicher mehr Entwickler auf seine Seite, als alle anderen Hersteller. Insbesondere Apple kann hier nicht glänzen, momentan ist es externen Entwicklern noch gar nicht möglich, echte Anwendungen für das iPhone zu schreiben, ein SDK soll erst kommendes Jahr folgen. Aber Google setzt auf die weit verbreitete Sprache Java zur Entwicklung, mit der echte Anwendungen und nicht nur AJAX-Geraffel geschrieben werden können.
Interessant wäre noch zu erfahren, ob es Pläne für Adobes Flash und Android gibt. Vielleicht wäre es die Gelegenheit das unsägliche Flash Lite über Bord zu werden und auf leistungsfähige CPUs und reguläre Flashplayer zu setzen. Aber auf der anderen Seite, sollen mit Java auf dem iPhone User-Interfaces möglich werden, die denen von Flash nicht in viel nachstehen.
Gegen Apples Proprietät setzt Google auf Offenheit der gesamten Lösung, die sich lizenztechnisch in der liberalen Apache 2.0 Lizenz niederschlägt.
Und man darf nicht vergessen, Android ist noch in einer sehr frühen Phase. 1.0er Versionen darf man in etwa mit dem Erscheinen der ersten Android-Endgeräte in der zweiten Hälfte 2008 erwarten.
Bei den AJAX-Frameworks tut sich was.
In der letzten Woche sind neben der 1.0 Version von Dojo auch die Versionen 1.6 von Prototyp und die Version 1.8 von script.aculo.us erschienen.
Gerade mit dem stabilen 1.0er Release von Dojo, das nach Jahren der Entwicklung und heftiger Unterstützung durch die Software-Industrie (IBM, Sun und AOL), fertig geworden ist, verbinden sich viele Erwartungen nach einen Quasi-Standard im Bereich AJAX-Entwicklung.
Als ich vor ca. einer Woche zu der “Unterschriftenaktion” für ein Java 6 unter Mac OS X Leopard schrieb, war die Aktion gerade einmal ein Tag alt und bei Google ließen sich etwas weniger als 200 Vorkommen des Strings “13949712720901ForOSX” finden.
Heute nach einer Woche gibt die Google-Suche bereits 12.700 Einträge aus. Eine erstaunliche Zahl dafür, dass die Aktion quasi nur durch Blogs bekannt gemacht wurde. Hoffentlich werden es noch einmal deutlich mehr und hoffentlich bewirkt die Aktion etwas…
Wer unter OS X 10.5 Leopard auf der Shell
java -d64 -version
eingibt wird sicherlich erstaunt bis enttäuscht sein, dass er keine 64bit Version angezeigt bekommt, vorausgesetzt er hat eine 64bittige CPU, etwa den Core 2 Duo. Die Ausgabe lautet:
Cannot run Java in 64 bit mode. Continuing in 32 bit mode.
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
Nichts desto trotz ist das Java unter Leopard natürlich 64bit fähig. Laut einem Eintrag auf der Apple Mailingliste handelt es sich um einen kleinen Bug. Man kann das 64bittige Java erzwingen, wenn man den vollen Pfad zu “java” aufruft. Die Eingabe
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Commands/java -d64 -version
erzeugt wie erwartet die Ausgabe:
java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_13-119, mixed mode)