Hat man sein Nexus One nicht direkt bei Google in den USA gekauft, sondern zum Beispiel bei Vodafone, bricht das Update auf Android 2.2 aufgrund einer falschen Prüfsumme schon vor der Installation ab. Hier heisst es dann eigentlich warten, bis Vodafone Android Froyo selbst verteilt.

Wer nicht warten möchte sondern trotzdem auf die aktuelle Version updaten will kann das tun, muss aber vorher seinen Bootloader entsperren und die aktuelle Firmware aufspielen. Ich habe hier in einer kleinen Anleitung zusammengefasst was ich Schritt für Schritt beim Update getan habe. Bei mir ist inzwischen die heute veröffentlichte Build Version Android 2.2 FRF91 installiert und ich kann über keinerlei Probleme klagen.

Ein Hinweis vorab: Wurde der Bootloader einmal entsperrt lässt er sich nichtmehr sperren. Beim Einschalten des Nexus One wird ab diesem Zeitpunkt unter dem Logo ein kleines geöffnetes Schloss angezeigt. Dabei erlischt die Garantie.

Vorbereitungen

Folgende Dateien werden während der Installation benötigt:

• fastboot.zip (373 KB)
• PASSIMG_Passion_Google_WWE_1.01.1700.1_ERD79_release_signed.zip (78 MB)
• signed-passion-ERE27-from-ERD79.a487b405.zip (16 MB)
• signed-passion-ota-42745.dc39ca1f.zip (82 MB)
• signed-passion-FRF91-from-FRF85B.db99fdf1.zip (910 KB)

Da Google die Downloads inzwischen entfernt hat und ich nicht weiss, ob ich die Dateien überhaupt selbst hosten darf, werde ich diese hier nicht hochladen.
Allerdings findet man alle Files problemlos bei einer Google Suche.

Wer möchte kann hier auch die SHA1 Checksummen der gefunden Dateien prüfen:

e3798bf97777bf00d095913a96a55e3969518dd3
PASSIMG_Passion_Google_WWE_1.01.1700.1_ERD79_release_signed.zip

db99fdf11a5059c903b4cdef9c355b9df5251db0
signed-passion-FRF91-from-FRF85B.db99fdf1.zip

Vor den hier beschriebenen Schritten sollte man USB-Debugging für das Nexus One einschalten. Die entsprechende Option findet sich unter Einstellungen -> Anwendungen -> Entwicklung -> USB-Debugging. Eine Sicherung der vorhanden Daten sollte selbstverständlich sein.

Noch ein Wort zur Navigation:
Im Bootloader navigiert man mit den Lautstärketasten an der linken Geräteseite. Mit der Power-Taste wird die ausgewählte Menüoption bestätigt.
Im Recovery Programm kann der Trackball benutzt werden.

Bootloader entsperren

1. Nexus One abschalten.
2. Trackball drücken und Gerät wieder einschalten um in den Bootloader zu gelangen.
3. fastboot.zip entpacken und je nach Betriebssystem das entsprechende Script mit folgenden Parametern ausführen:
   ./fastboot-linux oem unlock
   Hinweis von Carsten aus den Kommentaren: Unter Linux muss Fastboot eventuell mit Rootrechten ausgeführt werden.

Auf dem Nexus One erscheint jetzt eine Abfrage ob der Bootloader wirklich entsperrt werden soll. Diese Abfrage einfach bestätigen.

Downgrade auf Firmware ERD79

1. PASSIMG_Passion_Google_WWE_1.01.1700.1_ERD79_release_signed.zip im gleichen Verzeichniss wie fastboot entpacken.
2. Auch hier wieder Nexus One abschalten.
3. Trackball drücken und Gerät wieder einschalten um in den Bootloader zu gelangen.
4. /fastboot-linux devices
   sollte das mit dem USB-Kabel verbundene Gerät anzeigen.
5. Danach folgende Befehle ausführen:
   
./fastboot-linux erase cache
./fastboot-linux flash userdata userdata.img
./fastboot-linux flash boot boot.img
./fastboot-linux flash system system.img
./fastboot-linux flash recovery recovery.img
./fastboot-linux reboot


Bei mir waren dann folgende Ausgaben auf dem Bildschirm zu sehen:

sending 'userdata' (2 KB)... OKAY
writing 'userdata'... OKAY
[echox@kaffeesatz:~/android/froyo/fastboot] % ./fastboot-linux flash boot boot.img
sending 'boot' (2044 KB)... OKAY
writing 'boot'... OKAY
[echox@kaffeesatz:~/android/froyo/fastboot] % ./fastboot-linux flash system system.img
sending 'system' (116663 KB)... OKAY
writing 'system'... OKAY
[echox@kaffeesatz:~/android/froyo/fastboot] % ./fastboot-linux flash recovery recovery.img
sending 'recovery' (2294 KB)... OKAY
writing 'recovery'... OKAY
[echox@kaffeesatz:~/android/froyo/fastboot] % ./fastboot-linux reboot
rebooting...


Nach einer kurzen Wartezeit ist die neue Firmware dann aufgespielt.
Von hier können wir jetzt einfach bis auf Android 2.2 FRF91 Updaten.

Update auf ERE27, FRF85B (Froyo) und FRF91 (Froyo)

1. Nexus One über USB-Kabel mit dem Rechner verbinden.
2. signed-passion-ERE27-from-ERD79.a487b405.zip in update.zip umbenennen und auf die SD-Karte des Androids speichern.
3. Nexus One abschalten, Trackball drücken, Gerät wieder einschalten um in den Bootloader zu gelangen.
4. Im Bootloader sollte ausgewählt sein, mit der Power-Taste dann bestätigen.
5. Recovery auswählen und wieder mit der Powertaste bestätigen.
   Wenn ein Ausrufezeichen und ein kleines Android Logo zu sehen ist, die Power-Taste drücken und dann dazu die Volume-Up-Taste.

   Die Meldung "E:Can't open /cache/recovery/command" kann dabei getrost ignoriert werden.

6. Hier mit dem Trackball "Apply sdcard:update.zip" auswählen und einfach mit dem Trackball bestätigen.

Danach erfolgt die Installation und nach einem Neustart ist die Firmware ERE27 installiert.

Diese Schritte müssen als nächstes einfach für die Datei "signed-passion-ota-42745.dc39ca1f.zip" und anschliessend für "signed-passion-FRF91-from-FRF85B.db99fdf1.zip" wiederholt werden.

Danach ist die aktuelle Android 2.2 Version auf dem Nexus One installiert.

Ich habe dafür mit dem Suchen der Files knapp 20 Minuten gebraucht.

Update: Wer eine Anleitung für Android 2.2 "Froyo" auf dem Desire sucht, wird bei Fabian fündig.

Update 2:Stephan hat in den Kommentaren noch ein paar Hinweise zur Benutzung von Windows 7 gegeben:

Vorab musste ich die Datei "AdbWinApi.dll", sowie die "AdbWinUsbApi.dll" in den entpackten fastboot-Ordner kopieren - ansonsten kam die Fehlermeldung, dass die AdbWinApi.dll fehle.
Außerdem musste ich - da ich Win7 nutze - die Eingabeaufforderung als Admininstrator ausführen, um den Bootloader erfolgreich zu entsperren und das Downgrade auf ERD79 anzustossen zu können.

Das System funktioniert dabei so: Zuerst entscheide ich mich, welchen Betrag ich monatlich bezahlen will, um Inhalte die mir gefallen zu unterstützen. Dieser Betrag können 2, 5, 10 oder 20 Euro sein.

Habe ich nun zum Beispiel einen Blogartikel gelesen, der mir gefällt, kann ich diesen Artikel “flattrn”. Dazu muss der Autor bei Flattr teilnehmen und einen der Buttons in seinem Blog eingebunden haben. Durch einen Klick auf diesen Button ist der Artikel oder Blog dann “ge-flattrt”.
Am Ende des Monats wird der vorher festgelegte Betrag dann durch die Anzahl der “ge-flattrten” Inhalte geteilt und an die jeweiligen User ausbezahlt.

Hier wird das Prinzip noch einmal anschaulich mit Kuchenstücken erklärt:

Ich für meinen Teil, werde Flattr jedenfalls eine gewisse Zeit testen.
Seit einer kleinen Ewigkeit lese ich zum Beispiel nodomain.cc, freue mich über die kurzen Reviews und den ein oder anderen Tip. Netzpolitik.org ist ebenfalls aboniert, Isotopp, den Chaos Radio Express Podcast höre ich auch regelmässig.

Mit Flattr ist das jetzt ein Klick und jeder bekommt was vom Kuchen. Eine hausgemachte Kulturflatrate also, bei der ich selbst einen Einfluss darauf habe, wer meine Unterstützung bekommt.
Die TAZ ist dabei auch schon auf den Zug aufgesprungen.

Eingezahlt werden kann mit Moneybookers oder PayPal was bei mir ohne Probleme funktioniert hat. Der Support scheint aber, falls jemand Probleme haben sollte, auch recht fix zu sein, wie man auf Twitter lesen kann.

Mehr gibt es in der “Introduction” oder “The Flattr Story” auf der Homepage des Dienstes.

Flattr ist im Moment noch in der Beta Phase. In Web 2.0 Zeiten heisst das, man braucht einen Invite um daran teilnehmen zu können. Dafür kann man auf der Homepage seine E-Mail Adresse hinterlassen.

Ausserdem hätte ich noch 2 Invites über, also einfach kurz ein Kommentar hier lassen.

Erweiterungen der Virtuellen Maschine

Diese Erweiterungen betreffen nur die Virtuelle Maschine HotSpot von Sun. Wer eine andere Lauftzeitumgebung nutzt, zum Beispiel die Netweaver Plattform oder die Apache Harmony Plattform, den betreffen diese Erweiterungen nicht.

G1

Offiziell verfügbar wird mit diesem Release eine neue Variante des Garbage Collectors, genannt G1 (“Garbage First”). G1 ersetzt damit die bisherige “Concurrent Mark-Sweep” (CMS) Methodik von HotSpot.
Oberflächlich erklärt geht CMS so vor, dass der Speicher in verschiedene Bereiche eingeteilt wird. Diese Speicherbereiche enthalten die Objekte je nachdem wie lange ihre Lebensdauer ist. Es existiert ein Bereich für sehr langlebige Objekte, für kurzlebige Objekte, etc. Dabei wird vom Garbage Collector der Speicher durchlaufen und alle nichtmehr referenzierte Objekte werden gelöscht.
Da der Speicher mit der Zeit fragmentiert, muss dieser irgendwann defragmentiert werden, indem die Objekte im Speicher umkopiert werden. Genau hierfuer muss die VM für einen kurzen Moment angehalten werden, was Performance kostet.
Ziel von G1 ist es, genau diese Phasen zu reduzieren. Dabei wird davon ausgegangen, dass je länger ein Objekt “lebt”, desto wahrscheinlicher ist, dass es nicht mehr referenziert wird und der Speicher freigegeben werden kann. Je weniger Objekte am Ende existieren, desto kürzer dauert das Kopieren der noch verbleibenden Objekte und desto langsamer fragmentiert der Speicher.
G1 teilt dafür den Speicher in 1MB Bereiche ein und versucht vorauszusagen, wann die Objekte in diesen Bereichen ihre Lebenszeit überschritten haben. Den Objekten wird also genug Zeit zum “sterben” gegeben.
Eine ausführliche Erläuterung des Algorithmus findet sich im Paper “Garbage First Garbage Collection” (pdf) von Sun.
“Garbage First” ist übrigends schon seit Java 6 Update 14 als Backport enthalten und kann mit folgenden VM Parametern aktiviert werden:

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

InvokeDynamic

Die HotSpot VM ist seit längerer Zeit ja nicht nur eine Plattform für Java Anwendungen. Die VM interpretiert in erster Linie Bytecode und dieser kann, wie bei Microsofts .NET, von unterschiedlichen Sprachen kommen. In diesem Umfeld wären da JRuby, Jython, Scala oder Groovy zu nennen. Problem bisher ist allerdings, dass Java eine typisierte Sprache ist, es wird also schon vor dem Übersetzen der Anwendung festgelegt, von welchem Datentyp die benutzten Variablen sind. Sprachen wie beispielsweise Jython sind allerdings nicht typisiert. Hier werden die Datentypen dynamisch verwaltet. Bisher gibt dafür keine Unterstützung im Bytecode auf VM Ebene, was zu lasten der Perfomance geht. Das bei Java 7 enthaltene JSR 292 führt im Bytecode ein “InvokeDynamic” ein. Dadurch sollte die Performance von nichttypisierten Sprachen in der VM verbessert werden. Weitere Infos sind im “Da-Vinci Machine” Projekt zu finden.

Komprimierte 64-Bit Pointer

Innerhalb des VM Speichers gibt es OOPs, sogenannte “Ordinary Object Pointer”. Diese Pointer zeigen auf beliebige Objekte im Speicher. Dabei ist Objekt nicht im Sinne der objektorientierten Porgrammierung zu verstehen, sondern kann auch ein Element eines Objekts sein (zum Beispiel Instanzvariablen, Objektmetadaten, etc.). Pointer sind auf einem 64-Bit System normalerweise auch 64-Bit gross. Durch das hinzuaddieren einer fixen Speicheradresse kann die größe der Zeiger auch auf einem 64-Bit System auf nur 32-Bit reduziert werden. Dadurch wird der Speicherverbrauch und die Performance verbessert. Wer wissen möchte, wann genau die Pointer komprimiert werden und wie diese Komprimierung genau funktioniert findet im Sun Wiki eine ausführliche Erklärung mit Codebeispielen.

Modularisierung

Da das JDK und Java Anwendungen selbst immer größer und komplexer werden, gibt es schon lange Bestrebungen eine Schnittstelle und ein System zur Modularisierung der Komponenten zu schaffen. Um dieses System konsequent umzusetzen sind direkte Änderungen an den VM Spezifikation und der Sprache notwendig.
Mit dem JSR 294 werden diese notwendigen Änderungen in den Standard einfliessen.

Als Referenzimplementierung wird Sun ausserdem das Jigsaw Projekt bei seinen VMs hinzufügen. Ziel dieses Projekts ist zum einen, ein einfaches “low-level” Modulsystem zur Verfügung zu stellen, zum anderen um damit das JDK selbst zu modularisieren.

Wer jetzt an das schon jahrelang von der Industrie vorangetriebene OSGI denkt, liegt hier richtig. OSGI hat den gleichen Anspruch, setzt allerdings auf Java SE auf und ist nicht auf Sprach/VM-Ebene verankert. Was letztendlich das bessere Framework ist, darüber streiten sich die Java-Apostel. Auch ob OSGI und Jigsaw überhaupt in einem Widerspruch zueinander stehen. Sun selbst hat bisher in beide Systeme investiert und diese gefördert.

Sprachänderungen

Type Annotations

Die durch das JSR 308 vorgeschlagenen sogenannten “Type Annotations” sind inzwischen schon seit dem M4 Milestone im javac Compiler enthalten. Damit wird es möglich Annotationen nicht nur für Klassen und Methoden festzulegen, sondern für alle Datentypen. Dadurch wird zum Beispiel folgender Code zulässig:

List<@NonNull Object> foobar

Wer seinen Code trotzdem kompatibel zu älteren Java Version halten will, muss allerdings den javac Kompiler des “Type-Annotation” Projekts benutzen. Der lässt nämlich auch folgenden Code zu:

  List<!--*@NonNull*/ String--> strings;

Der OpenJDK Compiler wird hier die Annotation ignorieren, der des “Typ Annotation” Projekts nicht.

Project Coin

Mehrere kleine Sprachänderungen sind im “Project Coin” zusammengefasst.
Darunter fällt, dass man nun beim Switch-Statement Strings verwenden kann. Ein weiteres Feature wird automatisches Ressourcen Management sein. Wer beispielsweise mit Streams arbeitet, muss diese bisher explizit über eine entsprechende Methode schliessen. Beim automatischen Ressourcen Management wird der Stream dann in einen Try-Block eingeschlossen und beim verlassen dieses Blocks automatisch frei gegeben:

try (InputStream in = new FileInputStream(src);
    OutputStream out = new FileOutputStream(dest)) {
    byte[] buf = new byte[8192];
    int n;
    while ((n = in.read(buf)) >= 0)
        out.write(buf, 0, n);
}

Einfacher wird auch die Arbeit bei Zeichenfolgen mit Trennzeichen. Möglich wird einen Unterstrich in numerischen Datentypen zu nutzen:

int phone = 040_1234567_123;

Auch die Verwendung von Literalen in Collections verspricht Code weiter lesbarer zu gestalten. Damit kann eine Map im Stil eines Arrays initialisiert werden:

final Map PSE = { 1 : "H",
    2 : "HE", 3 : "LI",
    // ...
};

Die Initialisierung bezieht sich auf Collections, welche dann auch nicht mehr verändert werden können.
Gegenüber irgendwelchen statischen Codeblöcken die eine Map mit ihrer put-Methode initialisiert ist diese Version sicherlich einfacher.

Eingereicht wurden für das Project Coin über 60 Erweiterungsvorschläge, wovon es 9 ins JDK 7 geschafft haben. Eine vollständige Liste ist im Projektwiki zu finden.
Ich persönlich hätte mir ein vereinfachtes Exception-Handling gewünscht:

try {
// ...
} catch (fooException|barException ex) {
//...
}

Dieses Proposal hat es leider nicht ins JDK geschafft. Vielleicht klappts ja mit dem JDK 8.
Scheinbar ist man sich da noch nicht so wirklich sicher… Joe Darcy hat im Februar nochmal auf der Projektmailingliste bestätigt, dass wohl überlegt wird das Feature doch ins JDK 7 zu übernehmen. Bleibt wohl nur abwarten…

Project Lambda – Closures in Java

Lamda ist wohl das bisher am meisten diskutierte Java 7 Feature. 2008 wurde angekündigt, Closures wären jetzt doch nicht in der neuen Java Version vorhanden, 2009 wurde diese Ankündigung dann wieder zurückgezogen.

Closures sind im Prinzip das Zusammenspiel von zwei Sprachfeatures. Dabei benutzt man anonyme Funktionen um auf Variablen ausserhalb ihrer lexikalischen Sichtbarkeit zuzugreifen. Diese anonyme Funktionen werden Lamdas genannt. Closures sind eine weit verbreitete Technik und werden in anderen Sprachen wie zum Beispiel Ruby, Perl, Lisp und JavaScript häufig genutzt.

Ein Codebeispiel in JavaScript macht diese Erklärung sicherlich ein wenig verständlicher:

function foo() {
    var str = "bar";
    return function() {
        return str;
    }
 
    var myFoo = foo();
    alert(myFoo());
}

Die Variable str ist an der Stelle, an der sich der Aufruf von alert befindet, nicht im lexikalischen Bereich verfügbar. Trotzdem kann über eine anonyme Funktion darauf zugegriffen werden.

Hilfreich können Closures vor allem an solchen Stellen sein, wo häufig anonyme innere Klassen erzeugt werden, nur um eine einzige Methode zu benutzen. Wer an GUI Entwicklung mit Swing denkt, kann sich bestimmt vorstellen wie hilfreich Closures hier beim Eventhandling sein können.

Closures sind definitv geplant. Die endgültige Syntax steht allerdings noch nicht fest. Da aber der nächste Milestone näher rückt und es bis Herbst nicht mehr lange hin ist, wird man sich wohl in den nächsten Wochen auf eine Syntax festlegen müssen.
Wer am Entwicklungsprozess näher interessiert ist, der sollte einen Blick ins lambda-dev Mailinglistenarchiv des Projekts werfen.

Core

Fork And Join

Mit dem JSR166y wird das Fork and Join Framework von Doug Lea zum Teil des Java Standards. Um mehrere CPUs effizient nutzen zu können, ist es wichtig seine Anwendung entsprechend zu gestalten. Java bietet dazu den Threading-Mechanismus. Das Problem an Threads ist ein gewisser Overhead bei der Verwaltung. Threads müssen erstellet werden, pausiert, sind geblockt weil sie auf andere Threads warten, etc. Dieser Overhead ist unter umständen grösser als die eigentlich zu berechnende Aufgabe.

Bei der Fork/Join Technik geht es darum ein Problem in viele kleine Probleme zu zerlegen, die völlig unabhängig voneinander gelöst werden können. Anschliessend werden die Teilergebnisse zur Lösung zusammengefasst. Klassisches Teile- und Hersche Prinzip.
Gerade hier sind Threads aber als einziger Mechanismus in Java zu unflexibel um viele kleine Teilprobleme zu lösen. Probleme im Ablauf die Mechanismen wie Locking, etc. erforden, tauchen durch die unabhängigkeit der Teilprobleme voneinander garnicht auf.

Mit dem JSR166y wird ein flexiblerer Mechanismus zur Verfügung gestellt. Hier erstellt man für jedes Teilproblem einen sogenannten “Task”. Mehrere “Worker” arbeiten die so erstellten Tasks über eine Queue ab. Diese Queue unterstüzt sowohl das klassische Push/Pop für LIFO als auch take für FIFO.
Normalerweise wird ein Worker nach dem LFIO Prinzip seine Tasks abarbeiten. Sind alle Tasks berechnet, gibt es sogenanntes “Work-Stealing”. Dabei wird ein weiterer Task aus der Queue eines zufällig gewählten anderen Workers abgearbeitet, allerdings nach dem FIFO Prinzip. Da “ältere” Tasks wahrscheinlich grössere Probleme enthalten und oftmals wieder in kleinere Tasks zerlegt werden können, wird hierdurch der Verwaltungsaufwand immer wieder neue Tasks zu “stehlen” weiter minimiert.
Lea hat mit seinem Framework Benchmarks für verschiedene mathematische Algorithmen durchgeführt und dabei ist durchaus ein deutlicher Unterschied zu anderen üblichen Multithreading-Methoden zu sehen. Eine Einführung in das Framework, Fork and Join Prinzip und die Benchmarks sind in seinem Paper “A Java Fork/Join Framework” (pdf) zu finden.

NIO.2

Java bietet mit seinem I/O Paket eine Reihe von rudimentären Eingabe und Ausgabemechanismen wie Streams, Serialisierung und Zugriff auf das Dateisystem. Beim Release der 1.4er API wurde die Performance dieser Mechanismen verbessert und neue Features hinzugefügt. Diese Erweiterung umfasst beispielswiese Hilfsmittel für Zeichensatz Encoding/Decoding, Sprachsupport für Reguläre Ausdrücke, Channels, etc. Zusammengefasst ist diese Neue I/O API unter Java NIO.

Im JDK 7 wird das JSR 203 umgesetzt: “More New I-O APIs for the Java Platform”, kurz NIO.2.
Die Ziele von NIO.2 liegen dabei auf 3 Punkten:
Ein neues verbessertes Interface für das Dateisystem, lösen von Abhängigkeiten der Socket Channel Klassen und Unterstützung für asynchronen I/O Zugriff.

Für diese Änderungen war es eigentlich schon seit langem Zeit. Eine hervoragende Einführung in NIO.2 ist über Google Tech Talks auf YouTube verfügbar. Der Vortrag geht eine knappe Stunde und wird von Alan Bateman (Projektleiter für NIO.2) und Carl Quinn (Google) auf der JavaOne 2008 gehalten: The New NIO, aka JSR-203

Ausserdem ist im letzten Jahr ein Artikel welcher das neue Dateisystem Interface beleuchtet im Sun Developer Network erschienen: The Java NIO.2 File System in JDK 7

Classloader Änderungen

Sicherlich lädt nicht jeder Java Entwickler mit dem URLClassLoader seine Klassen selbst oder schreibt einen eigenen Classloader. Hier sind allerdings mit der Zeit unter anderem zwei Probleme aufgetaucht die in der neuen JDK Version gelöst werden:

In Java ist es nicht möglich zu bestimmen, wann der Garbage Collector nicht mehr referenzierte Ressourcen freigibt. Gerade bei zum Beispiel .jar Files die über den URLClassLoader geöffnet wurden, kann das in Kombination mit dem Windows Dateisystem Locking zu Problemen führen. Es lässt sich nicht sicherstellen, dass der Zugriff auf die geladenen Ressourcen zeitnah beendet wird. Der URLClassLoader implementiert nun aber das Closeable Interface. Hier können durch die Methode close() explizit der URLClassLoader und alle von ihm referenzierten Ressourcen geschlossen werden.

Beim Laden von neuen Klassen muss ein Classloader zuerst prüfen, ob eine Klasse nicht bereits geladen wurde. Wenn nicht, kann er diese innerhalb der VM definieren. Im Hinblick auf Multithreading und mehrere Classloadern innerhalb einer VM können sehr schnell komplexe und schwierig zu debuggende Probleme entstehen. Aus diesem Grund sind die meisten Methoden auf das Classloader Lock “synchronized”. Dadurch wird aber unter bestimmten Voraussetzungen ein klassisches Deadlock erzeugt.
Um dieser Problematik entgegenzuwirken wurden einige Änderungen an java.lang.ClassLoader vorgenommen. Unter anderem steht nun eine Methode registerAsParallelCapable() zur Verfügung, um mit einem Classloader explizit seine threadsafe Eigenschaft zu signaliseren.
Alle Änderungen sind im JDK 7 Classloader Proposal sehr transparent und übersichtlich erklärt. Hier wurden ebenfalls die verschiedenen Lösungsvorschläge und Vorgehensweise um das Problem zu beheben ausführlich dargestellt.

Updates für Solaris

Im OpenJDK gibt es auch zwei implementierungsabhängige APIs für Solaris: Es wird Support für die mehr oder weniger populären SCTP und SDP Protokolle geben.

Graphik

Bisher gibt es bei Java verschiedene Möglichkeiten Graphik zu rendern. Das Rendern über Software ist in der Regel deutlich langsamer, als wenn die Graphikhardware des Rechners benutzt wird. Dafür gibt es dann sogenannte Rendering Pipelines. Direct3D ist nur auf Windows Systemen verfügbar, für alle anderen Systeme gibt es OpenGL. Unter Systemen mit X11 ist das X11 eigene XRendering inzwischen allerdings fast Standard und auf einer größeren Bandbreite an Hardware verfügbar. In Java 7 wird es dann für Java2D eine eigene XRender Pipeline geben.

Sonstiges

Natürlich wird auch der XML Stack einem Update unterzogen, dass bedeutet die JAXP, JAXB, und JAX-WS APIs werden in der letzten stabilen Version vorliegen.
Das schon seit einer Weile enthaltene Swing Look&Feel Nimbus wird jetzt auch offizieller Standard.
Swing wird ausserdem um den neuen “JXLayer” ergänzt. Dieser Layer bringt “hübsches” sperren von Komponenten mit sich (Webstart Beispiel), Maus Auto-Scrolling (Webstart Beispiel) und noch ein paar Spielerein mehr.
Weiterhin wird Java ab der 7er Version den Unicode Standard 5.1 unterstützen (aktuell ist 5.2) und das kryptografische Verfahren ECC (Elliptic-Curve-Cryptography) von Haus aus unterstützen.

Closure Tools besteht aus den folgenden Teilprojekten:

Der Closure Compiler übersetzt JavaScript Code in eine kompaktere Form. Dadurch werden die Scripte kleiner und damit auch schneller. Es wird toter Code entfernt und nach üblichen Fehler gesucht. Eine Erweiterung für Firebug ist auch verfügbar.

Mit Closure Templates gibt es eine einfache Möglichkeit dynamisch HTML zu generieren. Die Templates sind fertig kompiliert als Java und JavaScript.

In diesem Posting geht es um den dritten Teil des Closure Projekts: Closure Library. Die veröffentlichte Bibliothek enthält eine breite Sammlung von Funktionen und ist kompatibel zu den gängigen Browsern.
Außerdem bringt sie noch ein paar andere nette Konzepte mit.

Abhängigkeiten

Closure Library besitzt ein simples Abhängigkeits-Konzept. Mit goog.provide() wird ein eigener Namensraum für eine Funktion geschaffen. Mit goog.require() ist es dann möglich auf die vorher definierten Funktionen zuzugreifen.
Dabei sind goog.provide() und goog.require() nicht nur als vereinfachte Include Funktionen zu sehen. Mit der Bibliothek kommt ein Python Script welches eine JavaScript Datei analysiert und mit den benötigten Abhängigkeiten ein grosses Script erstellt.
Dieses Script kann bei Bedarf dann mit dem Closure Compiler weiter optimiert werden.

Events

JavaScript sendet bei einer Benutzerinteraktion mit einem DOM-Element ein Event an dieses Element. Zum Beispiel bei einem Klick oder einem Kontakt mit dem Mauszeiger. Auf diese Events lässt sich dann im Programmcode reagieren. Leider sind Events bei jedem Browser ein wenig anderst implementiert. Auf diese Unterschiede müsste man eigentlich bei der Entwicklung achten. Closure umgeht dieses Problem mit einem eigenen Eventmodell. Dieses Modell funktioniert dann mit allen gängigen Browsern gleich.
Es ist auch möglich eigene Eventtypen zu erstellen und zu benutzen.
Die Demo goog.events.MouseWheelHandler zeigt zum Beispiel eine Reaktion auf Events des Mausrads.

Vererbung

Ein rudimentäres Vererbungskonzept wird mit goog.inerhits(child, parent) ermöglicht. Soll eine Klasse von einer anderen abgeleitet werden, muss goog.inerhits(child, parent) eine Refernz auf beide Klassen übergeben werden. Danach sind die vererbeten Funktionen sichtbar. Den Konstruktor der Vaterklasse muss man allerdings noch selbst aufrufen.

Ein Beispielcode aus der Dokumentation:

goog.ui.MenuButton = function(content, opt_menu, opt_renderer, opt_domHelper)
{
  goog.ui.Button.call(this, content, opt_renderer ||
      goog.ui.MenuButtonRenderer.getInstance(), opt_domHelper);
 
  // Menu buttons support the OPENED state.
  this.setSupportedState(goog.ui.Component.State.OPENED, true);
 
  if (opt_menu) {
    this.setMenu(opt_menu);
  }
  this.timer_ = new goog.Timer(500);  // 0.5 sec
};
goog.inherits(goog.ui.MenuButton, goog.ui.Button);

Hier erbt die Komponente MenuButton von Button. Zeile 3 zeigt den Aufruf des Konstruktor der Vaterklasse mit call().

Funktionen

Closure besitzt Funktionen für sehr viele Anwendungsfälle. Allein goog.ui enthält 138 verschiedene Komponenten. Dabei sind einfache Elemente wie ein Benutzerdialog genauso enthalten, wie eine Komponente zur Rechtschreibkorrektur, einer Baumstruktur oder einem kompletten WYSIWYG-Editor.
Es sind Datumsfunktionen vorhanden, einfache Iteratoren, komplexere Datentypen wie Maps und Sets, i18n-Funktionen zur Lokalisierung und einfache Effekte.

Wer sich selbst mit den Möglichkeiten vertraut machen will, dem Empfehle ich die API und die darin enthaltenen Demos.

Die komplette Bibliothek ist über Subversion verfügbar:

svn checkout http://closure-library.googlecode.com/svn/trunk/ closure-library-read-only

Achtung: Es sind hier auch alle Beispiele und Tests enthalten. Aus diesem Grund werden 156 MB heruntergeladen.

Closure Library ist verfügbar unter der Apache License 2.0.

• Bad Practice
• Correctness
• Experimental
• Internationalization
• Malicious code vulnerability
• Multithreaded correctness
• Performance
• Security
• Dodgy

In der Konfiguration ist es dann möglich, die einzelnen Pattern an/abzuwählen, nur schnelle Pattern prüfen zu lassen, das Reporting nach Kategorien zu beschränken oder mit Filtern spezielle Dateien von einer Pruefung auszuschliessen.

Hier ein kurzes Code Beispiel:

String str = new String("foo");
String str2 = new String();
if (str == str2) {
// ...

FindBugs kritisiert hier den String-Vergleich, welcher wahrscheinlich ueber die Equals-Methode des Strings gemacht werden sollte. Auch ist der explizite Aufruf des Konstruktors der Stringklasse in der ersten Zeile überflüssig.

Ein Beispiel für häufige Nullpointer Exception Fehler:

User user = Map.get("id3345");
if (user != null) {
user.refresh();
}
String pwd = user.getPassword();

Hier wird ausserhalb der Bedingung auf ein eventuell nicht vorhandenes Objekt zugegriffen. FindBugs markiert die entsprechende Stelle dann mit einer Warnung.

Implementiert eine Klasse das java.util.Iterator Interface ohne eine NoSuchElementException zu werfen, wird auch diese Klasse als Fehlerhaft makiert. So gibt es eine Unmenge an weiteren Beispielen im Handbuch, welches alle Pattern dokumentiert.

Wem die vorhanden Pattern nicht reichen, der kann relativ einfach selbst eigene Pattern erstellen und mit FindBugs benutzen. So lassen sich zum Beispiel auch Fehler in der falschen Benutzung von eigenen Frameworks finden. Chris Grindstaff von IBM hat ein kleines Tutorial dazu geschrieben: Writing custom bug detectors.
fb-contrib ist eine offene Sammlung eigener Pattern.

FindBugs muss übrigends nicht zwingend als Eclipse Plugin benutzt werden. Es gibt eine eigene GUI dafür und wer will kann es sogar als Ant-Task in seinem Deploymentprozess nutzen. Auch für Maven und Maven 2.0 gibt es inzwischen ein entsprechendes Plugin.
Hier ist der Download zu finden.
Plugin only: http://findbugs.cs.umd.edu/eclipse ist die offizielle Update Seite fuer den Eclipse Plugin Manager.

Rund 27.000 Entwickler haben sich dafür erfolgreich registriert, mit der API gespielt und kleine Prototypen in Form von Gadgets und Robots geschrieben.Die Java Robot Client Library wurde nun ganz offiziell als Open Source verabschiedet und ist bei Google Code zum download verfügbar.

Es wurden von verschiedenen Firmen Extensions entwickelt die jetzt von Google selbst unterstützt werden. Dazu zählen einfache Spiele wie Sudoku genauso, wie Video Chat Anwendungen und eine Wetter Erweiterung.

Eine Vorschau gibt es für Erweiterungen von SAP, salesForce.com (Stichwort Cloud Computing) und MediaWiki (dafür scheint Google Wave ja wie gemacht zu sein).

Ausserdem findet man bei den Extensions jetzt auch die “Wave Extension Design Principles”.

Wer bisher keine Lust oder Zeit hatte, sich das 80 Minuten Video zur Google Wave Präsentation auf der Google I/O anzusehen, hat nun die Möglichkeit in 8 Minuten eine Übersicht zu bekommen. Stephanie und Greg vom Entwicklerteam haben die Features nochmal schnell zusammengefasst:

Ob das etwas mit den 100.000 verschickten Einladungen zu tun hat?

Aus wird jedenfalls .

Laut dem offiziellen Blogposting von Stephanie sind die Einladungen naemlich schon raus.

To all sandbox developers, thank you for your patience, feedback, creativity and riding the sometimes bumpy waves with us. You will get accounts on wave.google.com tomorrow – check your sandbox account for instructions on how to login. You’ll also get invitations to bring on people you want to wave with or have try your extensions. Google Wave is more fun with friends or colleagues to collaborate with so use your invitations wisely!

Tatsächlich habe ich in meinem Developer Sandbox Account eine Einladung zur Betaphase auf wave.google.com gefunden.

In meinem Firefox 3.5 laeuft das Frontend inzwischen deutlich stabiler als in der Sandbox. Auche meine ich einen positiven Geschwindigkeitsunterschied feststellen zu koennen. Mehr kommt dann in den nächsten Tagen.

Aber testet doch am besten selbst, ich habe noch 4 Einladungen übrig

Hinterlasst dazu einfach einen kurzen Kommentar – First come, first served!

Panda Poken (Quelle: doyoupoken.com)

Es dient dazu, seine Kontaktdaten mit anderen Pokenbesitzern auszutauschen. Um diesen Austausch vorzunehmen muessen nur die Handflaechen beider Poken fuer 2-3 Sekunden aneinander gehalten werden. Nun werden ueber RF die Poken IDs ausgetauscht. Wenn alles funktioniert hat, leuchtet eine in die Handflaeche des Pokens integrierte LED kurz gruen auf. Leuchtet die LED rot auf, gab es einen Fehler und der Vorgang muss wiederholt werden.

Das eigene Profil in Form einer kleinen Visitenkarte pflegt man beim Hersteller doyoupoken.com direkt. Dort lassen sich auch die freigegebenen Daten der zuletzt getauschten Kontakte einsehen, nachdem man eine kleine HTML Datei auf seinem Pokenstick geoeffnet hat.

Features

Was auf der Pokenvisitenkarte angezeigt wird kann man selbst frei waehlen. Es stehen die VCard ueblichen Felder zur Auswahl, ausserdem lassen sich die meisten bekannten sozialen Netze hinzufuegen, ein Benutzerbild und ein eigener Hintergrund der Visitenkarte.

Poken Visitenkarte

Hier koennen auch mehrere Identitaeten angelegt werden, zum Beispiel laesst sich so eine Identitiaet fuer Geschaeftspartner und eine fuer Freunde anlegen. Welche von diesen Identitaeten nun an andere Poken uebertragen wird, laesst sich durch mehrmaliges druecken der Handflaeche des Pokens bevor man diese aneinander haelt auswaehlen.

Auch kann man dabei in eine Art “Ghost”-Modus schalten. Hier wird nur eine blanke Visitenkarte getauscht, erst wenn der Kontakt online bestaetigt wurde, ist die eigentliche Visitenkarte sichtbar.
Ueber doyoupoken.com koennen ausserdem die Kontaktkarten auch direkt im VCard-Format heruntergeladen werden.

Technik

Technisch gesehen basieren Poken eigentlich nicht auf einem komplizierten Prinzip. Jedes Poken besitzt eine eindeutige ID. Diese wird beim aneinanderhalten zweier Poken getauscht. Auf dem Poken befindet sich eine Start_Poken Html-Datei welche die Domain http://p.poken.ch aufruft.

In der URI ist ausserdem noch die eigene Poken ID enthalten, ausserdem die IDs der anderen Poken mit denen eine Kontakt stattgefunden hat. Die Begrenzung das maximal 64 Kontakte gespeichert werden koennen, bevor ein Abgleich mit der Homepage stattfinden muss liegt uebrigends nicht am Speicherplatz des Pokens (scheinbar ~ 1 Gig read-only), sondern an der Begrenzung von URIs auf eine feste Laenge.

Nach einem Login auf der Pokenseite werden dann einfach die so hinzugefuegten Kontakte gespeichert.

Kritik

Etwas enttaeuscht bin ich von der Verarbeitung des Pokens. Etwas Metall haette sich bei der Verarbeitung des USB-Steckers sicher besser gemacht. Beim einstecken in den USB-Port habe ich irgendwie immer Angst ich koennte in den naechsten 5 Minuten unguenstig an den Kanten meines Laptops haengen bleiben und das Poken abbrechen. Auch graut mir ein wenig vor dem ersten Batteriewechsel. Hierzu muss das Gehaeuse an der Unterseite mit einem Schraubenzieher aufgehebelt werden.
Hier waere eine selbstladende Batterie sicherlich um einiges praktsicher gewesen.

Die Idee des Pokens stammt uebrigends auch nicht direkt von der Firma Poken S.A. und ihrem Gruender Stéphane Doutriaux sondern wurde schon 2007 als Abschlussarbeit von einem kleinen niederlaendischen StartUp mit dem Namen E vorgestellt. Ueberhaupt gefaellt mir das Poken, genannt Connector dann doch eigentlich wesentlich besser. Leider befinden wir uns dort dann aber doch in einem wesentlich anderem Preissegment. Ausserdem scheint hier der Focus bei “Businessusern” zu liegen.

Ein weiterer Kritikpunkt ist fuer mich, dass ich meine Zugangsdaten zu den sozialen Netzen die ich verlinken will angeben muss. Laut doyoupoken.com ist das noetig, um zu verifizieren, dass ich auch wirklich hinter diesem Profil stecke. In meinen Augen voellig ueberfluessig, da ich die Person zuvor im echten Leben getroffen habe. Auch werde ich nach einer Kontaktaufname ueber das soziale Netz wahrscheinlich ziemlich schnell feststellen, ob der Account nun zur betreffenden Person gehoert oder nicht. Da gibt es in Sachen Sicherheit durchaus andere Baustellen.

Sicherheit

Vorab: Das Problem was sonst bei RFID haeufig kritisiert wird, naemlich das unbemerkte Auslesen von Informationen ist bei Poken eigentlich nicht moeglich. Benoetigt wird zum Auslesen ein direkter Kontakt von Empfaenger und Sender.

Traurig ist allerdings, dass eine Firma die 2009 nach eigenen Angaben 60.000 Produkte herstellt es nicht schafft, die Verbindung zu ihrem Dienst ueber SSL herzustellen. Die Homepage unterstuetzt zwar den Zugang ueber https, allerdings muss ich die Adresse selbst direkt eingeben. Eine Weiterleitung nach einem Klick auf Login besteht nicht. Rufe ich die Datei Start_Poken.html auf um meine Kontaktdaten zu uebertragen oder mein Poken zum erstenmal zu initialisieren, wird die Verbindung ebenfalls ueber http und nicht ueber https hergestellt. In Zeiten von offenen WLANs in Cafes, Konferenznetzen und Proxys eigentlich schon grob fahrlaessig. Erst recht wenn man noch unvorsichtigerweise das Auto-Login Feature aktiviert hat.
Laut doyoupoken.com wurde da bereits nachgebessert, aber ein tatsaechliches Ergebnis laesst sich nicht erkennen.

Auch hat sich der belgische Sicherheitsexperte Didier Stevens das Poken naeher angesehen und festgestellt, dass neben der Poken ID im Klartext (Base64 ist keine Verschluesslung…) eine Verschluesslung mit maximal 64 Bit eingesetzt wird. “State-of-the-art” ist etwas anderes. Sollte diese Verschluesslung tatsaechlich geknackt werden, waere es wahrscheinlich moeglich beliebige Kontaktdaten die hinter Poken IDs stecken einzusehen. Natuerlich wird niemand mal eben 64 Bit brechen. Aber trotzdem, die Frage was da aber bei einer ernsthaften Traffic-Analyse waehrend des Pokens herauskommt, ist sicherlich berechtigt.

Ausblick

Kuerzlich wurde von Dave Brown der Poken Hub vorgestellt. Wer jetzt direkt an ein Stueck Hardware denkt hat eine falsche Vorstellung . Der Poken Hub ist eine Software die ein Poken als Empfaenger benoetigt. Meldet sich jetzt jemand an diesem Poken an, wird die Software getriggert und kann verschiedene Aktionen ausloesen. Ein Beispiel waere zu twittern, dass Person xy jetzt eingetroffen ist. Der Hub ist ueber Plugins erweiterbar. So koennen Pokens also auch als Token benutzt werden. Wann es den Hub tatsaechlich zu kaufen gibt, ist noch unklar.

Auch wurde inzwischen angekuendigt doyoupoken.com um eine offene API zu erweitern. Damit liese sich wahrscheinlich der Poken Hub mit einer handvoll Zeilen Perl problemlos genauso erweiterbar nachbauen. Wie diese API aussehen soll, wann sie kommt und welche Features unterstuetzt werden ist noch nicht bekannt, allerdings gibt es ein Posting zur Philosophie dahinter.

Da die Abfrage der Zugangsdaten beim hinzufuegen von sozialen Netzen in der Kritik stand, wird hier inzwischen auch daran gearbeitet einen anderen Authentifizierungsmechanismus einzubinden. Ich nehme an, hier wird einfach die API des anderen Netzes benutzt, falls dieses verfuegbar ist.

Bleibt abzuwarten was die API hergibt.
Mein Poken sieht uebrigends so aus:

Mein Ninja Poken

Weitere Informationen:

Hersteller DoYouPoken.com

Hersteller Blog

MyPoken.org

Erfahrungen mit Pokens im “Business”

Pokenonline Infoseite + Shop

Pokenshop Missionpoken.de

Ein anderer Pokenshop

Laut eigener Aussage ist putpat das “neue Musikfernsehen”.
Das ist gut, Musikfernsehen vermisse ich naemlich schon seit geraumer Zeit.
Bei den grossen Sendern laufen ja seit einigen Jahren ja leider kaum mehr tatsaechliche Musikformate und meistens kommt auch nicht unbedingt Musik die mir gefaellt.

Vom Radio habe ich mich musikalisch auch schon lange verabschiedet. Im Streaming Dienst last.fm habe ich aber dafuer einen hervorragenden Ersatz gefunden. Bei last.fm hat man die Moeglichkeit, die von sich gehoerten Lieder, automatisch speichern zu lassen. Daraus wird dann fuer den Benutzer eine Statistik erstellt. Mit dieser Statistik kann man sich dann seinen persoenlichen Radiostream generieren lassen. Dieser Stream setzt sich dann aus Kuenstlern des eigenen Musikstils zusammen. So lernt man ganz von selbst relativ viele neue Musiker kennen.
Am Anfang war ich neugierig ob dieses System funktioniert, aber nach dem ersten Test schon voellig begeistert.

Fuer Musikvideos uebernimmt diese Aufgabe putpat.tv.
Man gibt bei der Registrierung einfach seine Lieblingsbands oder den last.fm Benutzernamen an, und daraus wird ein peronalisierter Videostream erzeugt. Wem hier die Abwechslung fehlt, der hat noch zusaetzlich die Moeglichkeit zwischen verschiedenen Programmformaten (Jazz, Rock, …, Intro, Festivalguide) zu waehlen.
putpat.tv speichert dann auch hier wieder, welche Videos man mag und welche man nicht sehen will.

Bisher ist meine Erfahrung damit nur positiv. Die Daten aus meinem Last.fm Profil wurden Problemlos uebernommen und inzwischen liefen bei mir schon einige Stunden Video ueber das Netz. Die Qualitaet der Videos ist kein HD, allerdings trotzdem wirklich sehr gut. Wer eine schmale Internetanbindung hat kann die Qualitaet auch problemlos in seinen Einstellungen veraendern.

Die Auswahl der Musik entspricht zwar meinem Geschmack, koennte allerdings noch abwechslungsreicher sein. Man kann aber wohl davon ausgehen, dass sich das mit der Zeit noch aendern wird. Schliesslich muessen die Videos erstmal putpat zur Verfuegung stehen.

Der Dienst befindet sich im Moment noch in der Beta Phase. Eine Registrierung ist noch nicht Selbststaendig moeglich. In Regelmaessigen Abstaenden gibt es allerdings wohl die Moeglichkeit Freunde einzuladen. Zudem kann man sich selbst um einen Zugang bewerben, was wohl nicht lange dauert.

Ich fuer meinen Teil bin zufrieden und warte ab, wie sich der Dienst in Zukunft finanziert. Nach eigenen Angaben laeuft das ueber Reklame:
“Das bringt zwar mit sich, dass man ab und zu mit ein paar verkaufsfördernden Elementen konfrontiert wird. Aber da muss man durch.”
Bisher habe ich ausser auf dem Festivalguide-Kanal davon aber noch nichts bemerkt. Nimmt hoffentlich in Zukunft nicht ueberhand.

Hier zeigt Lars Rasmussen mit seinem Team schoen ueber mehrere Rechner verteilt wie einfach es ist, mit den Google eigenen Wave Applikationen zu Chatten, Teilnehmer zum Chat hinzuzufuegen, private Gespraeche zu fuehren, die History zurueckzuspielen und Dokumente zu tauschen. Bildergalerien werden einfach per “Drag and Drop” in die Anwendung gezogen worauf hin fast sofort eine Vorschau mit Thumbnails entsteht, obwohl die Bilder noch nicht komplett hochgeladen wurden.

Besitze ich nun einen Blog, kann ich diese Bildergalerie direkt aus Google Wave heraus einbinden. Aenderungen, zum Beispiel an einem Bildtitel, werden sofort sichtbar.
Das bedeutet Tastenanschlag fuer Tastenaschlag wird unmittelbar uebertragen. Ich kann meinem Kommunikationspartner also beim Tippen zusehen.

Die in der Einfuehrung gezeigte Webapplikation ist uebrigends mit dem Web Toolkit und HTML 5 gebaut[2].

Doch was ist denn Google Wave eigentlich ohne die bunten Webapplikationen betrachtet?

Protokolluebersicht

Google Wave ist vor allem erstmal ein erweitertes XMPP Protokoll. Damit erben wir sozusagen saemtliche Bestandteile von Jabber, das heisst die XML Basis, Adressierung, TLS, Buddylist-Konzept, etc.

Jetzt gibt es in Google Wave sogenannte Wavelets. Ein Wavelet besteht aus einer eindeutigen ID, einer Liste mit Berechtigungen und einem Satz von XML Dokumenten. Dieses Wavelet liegt dann beim Waveprovider des Erstellers. Moechte man nun dieses Dokument mit anderen Benutzern teilen, fuegt man die Benutzer der Berechtigungsliste hinzu. Die anderen Benutzer koennen dabei zum Beispiel nur Leserechte haben oder ebenfalls auch Schreibrechte.

Am Anfang wird dann der Wave Provider des Benutzers eine Kopie der fuer ihn zugaenglichen XML Dokumente erhalten. Aenderungen an den Dokumenten des Wavelets werden von da an in Echtzeit durch das Google Wave Protokoll an alle anderen Benutzer uebertragen. Durch jede Eingabe, jeden Tastenanschlag, entsteht also eine eigene “Wave”mit den Aenderungen zur vorherigen Dokumentenversion. Durch dieses System entstehen verschiedene Versionen der Ursprungsdokumente. Diese Versionen koennen jederzeit problemlos angefordert werden,  so entsteht ganz automatisch eine beliebig flexible History. Es ist also nicht nur moeglich einen Schritt zurueck zu gehen, sondern man kann ganz gezielt den Urzustand einer bestimmten Stelle des Dokuments herstellen.

Google Wave  ist also erstmal nur ein Protokoll, um Aenderungen an Dokumenten in Echtzeit zu publizieren.

Anforderungen und Probleme

Um diese Technik nutzen zu koennen benoetige ich also einen Wave Provider und meine Anwendung, welche die erstellten XML Dokumente in einer brauchbaren Form rendert.

Wave Provider wird es ueber kurz oder lang wohl recht viele geben. Da das Protokoll “Open Source” und recht ueberschaubar ist, wird es wahrscheinlich kein Problem sein, einen eigenen Server zu schreiben. Zur Google eigenen Serversoftware wurde im Vortrag leider nichts gesagt, auch nicht ueber die Systemanforderungen. Anforderungen sind fuer mich jetzt schlecht abzuschaetzen, aber ich denke hier wird es hohe Ansprueche an die Infrastruktur geben. Ich bin selbst kein grosser Freund von XMPP/Jabber, aber die grossen Jabber Server haben immer wieder Probleme durch erhebliche Netzlast die zum Beispiel durch Onlinestatus-Updates der Benutzer generiert werden. Jeder kann sich selbst ausrechnen was fuer Traffic generiert wird, wenn wirklich viele Benutzer, zum Beispiel waehrend einer Konferenz, ein Dokument in Echtzeit bearbeiten. Auf die technischen Probleme von XMPP/Jabber wird im Wiki zu PSYC entsrpechend eingegangen[3].

Ein weiteres Problem sehe ich in der Strukturierung des XMLs. Google zeigt zwar waehrend der Demo schoen, wie einfach es ist gemeinsam Dokumente zu bearbeiten und das jeder sich im Prinzip seinen eigenen Wave Server aufsetzen kann, trotzdem muesste dann auch das Dokumentnformat irgendwo spezifizieren da sich die darin enthaltenen Informationen sonst nicht rendern lassen. An eine offene Spezifikation aus der Community will ich irgendwie noch nicht so recht glauben.

Ob Google Wave also wirklich die Technik fuer eine neue Kommunikationsform wird, haengt vor allem davon ab, ob man sich gemeinsam auf ein entsprechendes Format zur Uebertragung dieser Kommunikation einigen kann. Bei Google Groups zum Thema Wave Protokoll wurde diese Problematik wohl kurz angesprochen[4], inzwischen scheint die Diskussion aber eingeschlafen zu sein.

In der Google Wave Robots API gibt es zwar ein Interface “Blip”[5], welches einen Knoten in einer Kommunikation repraesentiert, genauere Spezifikationen habe ich aber dazu leider noch nicht finden koennen.

Ausblick

Sicher das Wave Protokoll ist eine nette Sache. Ob es aber tatsaechlich die Kommunikation im Netz so massgeblich beeinflussen wird, wie ueberall prophezeit bleibt abzuwarten.

Sicher kann man sich aber sein, dass dieses Protokoll auf jedenfall kommen wird. Google hat die ersten Teile der Spezifikationen oeffentlich zugaenglich gemacht und ein kleines API Kit in Java und Python fuer Robots und aehnliche Anwendungsfaelle zur Verfuegung gestellt. Die Teilnehmer der Google IO Konferenz haben alle einen Sandbox Zugang erhalten und koennen vorab die Google Anwendungen und das Protokoll testen.

Mit der Zeit wird man sicher immer mehr Robots als Service zur Verfuegung haben. Anwendungsfaelle wie zum Beispiel eine schicke kontextabhaengige Rechtschreibkontrolle, automatisiertes Bloggen, etc. wurden ja im Vortrag schon demonstriert. Das die Google App Engine Python und Java unterstuetzt ist sicherlich auch kein Zufall und so findet man fuer kleinere Robots hier sogar in Google einen kostenlosen Hoster.

Ich bin gespannt was beim Sandboxtest rauskommt und wie gut das Protokoll tatsaechlich in einer echten Umgebung skaliert. Die Performance Problematik habe ich ja oben kurz angesprochen…

Ausserdem interessiert mich wie Google den Open Source Prozess umsetzt. Traditionell bestehen die Committer und Maintainer (also die Leute welche Aenderungen am Protokoll auch wirklich einspielen koennen) ja aus der Community welche entweder durch eine spezielle Gruppe ausgewaehlt werden oder eben direkt gewaehlt sind. Natuerlich bedeutet Open Source nicht die Verpflichtung diese Aufgaben an eine Community zu geben, aber die “Community Principles”[6] lassen auf etwas in dieser Richtung schliessen. Im Moment sind die Committer selbstverstaendlich noch die Entwickler bei Google[7] selbst.

Weiterfuehrende Links

Wer sich mit dem Thema naeher befassen will, dem empfehle ich folgende Links:

Einfuehrung von Google Wave auf der Google IO

Ein erster Entwurf der Protokollspezifikationen

Uebersicht ueber die Protokollarchitektur

Google Groups Diskussionen

Google Wave APIs

Fussnoten:

[1] Google Wave Introduction from Google IO – http://www.youtube.com/watch?v=v_UyVmITiYQ

[2] Went walkabout. Brought back Google Wave – http://googleblog.blogspot.com/2009/05/went-walkabout-brought-back-google-wave.html

[3] Technical Issues in Jabber – http://about.psyc.eu/Jabber

[4] Google Groups: Wavelets with different XML schemas – how to render? – http://groups.google.com/group/wave-protocol/browse_thread/thread/2d3fb5ce88dc3249

[5] Google Wave Robots API Javadoc – http://wave-robot-java-client.googlecode.com/svn/trunk/doc/index.html

[6] Google Wave Community Principles – http://www.waveprotocol.org/wave-community-principles

[7] Google Wave Committers – http://www.waveprotocol.org/committers