Ich will hier kurz meine Erfahrungen mit dem Gerät schildern. Um es gleich vorweg zu nehmen: Der Kindle ist ein E-Book Reader, kein Multimedia Tablet.
Wer das Kindle als alternative zum iPad sieht, sollte sich den Blogbeitrag "Das unmagische Amazon Kindle" von 343max durchlesen.

E-Ink

Das Display ist bei einem E-Book Reader für mich das wichtigste Kriterium. E-Ink versucht dabei echtes Papier nachzuahmen. Das Display reflektiert dabei das Licht, leuchtet also nicht selbst. Der Vorteil dabei ist deutlich angenehmeres lesen. Bei starkem Sonnenlicht werden die meisten Displays von diesem "überleuchtet" und der Text ist nichtmehr zu erkennen. Bei einem passiven Display passiert das nicht.
Die benutzte Technik beim Kindle benötigt zur Anzeige keinen Strom. Das Bild wird einmal erzeugt und danach dauerhaft angezeigt, was sich positv auf die Akkuleistung auswirkt (1 Monat ohne WLAN).
Der Text sieht bei normalen Tageslicht perfekt aus. Bei einem neuen Gerät wird vor dem Einschalten eine Schnellstartanleitung auf dem Display angezeigt. Ich habe diese Anzeige im ersten Moment für eine Folie gehalten die als Schutz über das eigentliche Display geklebt ist. Soviel also dazu.
In Räumen die nicht hell ausgeleuchtet sind, wird der Hintergrund leicht grau, der Kontrast zum Text ist aber für mich immernoch ausreichend.
Das Schriftbild, Zeilenabstände und Schriftgrösse lassen sich den eigenen Lesegewohnheiten anpassen.
Was aufällt ist die in Anführungszeichen "langsame" Aktualisierung des Bildschirms. Beim Blättern auf die nächste Seite blinkt der Bildschirm für einen kurzen Moment auf, der Menüaufbau dauert dann schonmal ~ 1 Sekunde. Negativ fällt das allerdings nicht ins Gewicht. Ich will mit dem Gerät ja lesen und keine Filme schauen.

Usability

Der Kindle liegt zuerst etwas ungewohnt in der Hand. Man weiss erst nicht so ganz, wie man ihn anfassen soll. Unten gibt es die Tastatur und an den Rändern die Tasten zum blättern. 0,85 cm sind schon ziemlich flach. Irgendwie wusste ich am Anfang nicht so ganz wohin mit meinem Daumen...
Die zusätzlich gekaufte Hülle hat diesen Nachteil allerdings mehr als ausgeglichen. Wenn man die Vorderseite umschlägt hat man in etwa die Dicke eines Buches, was alles angenehm griffig macht. Das Gewicht ist mit 240 g ziemlich angenehm.

Die Menüführung ist im ersten Moment äusserst ungewohnt. Hier wird einem schnell bewusst, dass man kein Touchpad oder Smartphone in den Händen hält. Positiv ausgedrückt fühle ich mich an die Bediehnung eines 10 Jahre alten Handys erinnert.

Was mich allerdings wirklich stört, ist die Tastatur des Geräts. Die Steuertasten für den Cursor, zum Beispiel zur Auswahl der Menüpunkte oder zum Nachschlagen eines Wortes, sind zu klein. Direkt darunter ist die "Back" Taste angebracht, direkt darüber die "Menü" Taste. Wenn man nicht genau den Druckpunkt findet, landet man schnell an der falschen Stelle.
Absolut bescheuert ist die Eingabe von Zahlen: Man muss dazu auf die "Sym" Taste drücken und die Zahlen mithilfe des Cursors auswählen. Um also auf Seite 42 zu springen, muss man entweder 42x auf die Taste zum blättern drücken oder auf "Menu", "Go to" (einfach Enter), "Sym", Cursor zur 4 bewegen, "Enter", Cursor zur 2 bewegen "Enter"... Da hätte es definitv bessere Lösungen gegeben.
Die grossen Tasten links und rechts zum umblättern sind in meinen Augen allerdings angenehm positioniert.

Möchte man ein Wort nachschlagen ist es ausreichend den Cursor zum entsprechenden Wort zu bewegen. Es wird dann automatisch eine Beschreibung aus dem eingestellten Dictionary (zum Beispiel Oxford Dictionary oder Duden) unter oder über dem Text angezeigt. Der Lesefluss wird dabei nicht gestört.

An die Bedienung habe ich mich inzwischen recht schnell gewöhnt und bin eigentlich zufrieden.

Kindle Versionen und der Amazon Account

Den Kindle 3 gibt es in zwei Versionen. Eine Version mit WiFi für 139 Euro und eine Version mit Wifi + 3G für 189 Euro. Bei der Version für 189 Euro ist in Deutschland eine Verbindung ins O2 Netz sichergestellt. Darüber werden dann gekaufte Bücher an das Gerät übertragen. Gebühren fallen keine an.
Ich habe mich für die WiFi only Version entschieden. Mein Android Smartphone kann über Tethering als WLAN Accesspoint fungieren, was mit dem Kindle zusammen wunderbar funktioniert.
Das Gerät selbst ist automatisch mit dem Amazon Konto verknüpft, über das es gekauft wurde. Im Nachhinein lässt sich das natürlich auch ändern. Gekaufte Bücher werden dann an das Gerät übertragen. Eine ganze Reihe an Klassikern bei denen zum Beispiel das Urheberecht abgelaufen ist, werden von Amazon kostenlos angeboten.
Die im Kindleshop gekauften Bücher können immer wieder an die registrieren Geräte (zum Beispiel auch die Kindle App des iPads, Android, etc.) geschickt werden. Alternativ kann man natürlich auch seine Dateien über die USB Schnittstelle übertragen. Bookmarks, Notizen und aufgeschlagene Seiten werden ebenfalls synchronisiert.

Unterstützte Formate

Angezeigt wird das eigene Kindle-Format (.azw), Mobipocket (.mobi), PDF, Word, Text und HTML. Word und HTML habe ich nicht getestet. Bei .azw gibt es selbstverständlich keine Probleme. Mobipocket und Text funktionieren wie erwartet auch einwandfrei. Word und HTML habe ich nicht getestet.
Was absolut garnicht funktioniert ist PDF. Das Dokument wird zwar dargestellt, allerdings muss man umständlich über das Menü zuerst eine Zoomstufe einstellen und dann mit dem Cursor einen Bildausschnitt wählen. Hat man den Ausschnitt gelesen, muss man mit dem Cursor weiterscrollen. Zu gebrauchen ist die Funktion absolut nicht. Schade.
Wer allerdings E-Books im PDF Format hat, kann diese zum Beispiel mithilfe von Calibre problemlos in das Mobipocket-Format konvertieren. Dort kann man dann als Ausgabelayout dann auch Kindle einstellen. Der Umweg ist zwar unschön, erziehlt allerdings gute Ergebnisse.
Calibre kann übrigends auch EPUB konvertieren, solange kein DRM vorhanden ist.

Und sonst?

Als experimentelle Funktionen wird noch ein Browser angeboten. Ja man kann mit dem Kindle im Internet surfen. Nein, man will mit dem Kindle nicht im Internet surfen. Die Benutzerfreundlichkeit entspricht in etwa der vom lesen eines PDFs. Ausserdem sieht die Schrift hier oft ziemlich verwaschen und unscharf aus.
Zu erwähnen wäre noch die Möglichkeit, einer Vorlesefunktion und MP3s abzuspielen. Dafü gibt es einen 3,5mm Klinken Ausgang oder interne Lautsprecher. Beide Funktionen sind für mich nicht wirklich relevant. Bücher kaufe ich, damit ich sie selbst lesen kann und MP3s höre ich über meinen MP3-Player oder Smartphone.

In Kurz

Wie eingangs schon erwähnt ist der Kindle ein reiner E-Book Reader und dafür funktioniert er sehr gut. An die Handhabung habe ich mich relativ schnell gewöhnt.
Das Display schlägt alles was ich bisher in dieser Richtung gesehen habe.
Formatmässig unterstützt er .AZW und Mobipocket. Wer PDF und EPUB will muss diese Formate konvertieren. Blogs, RSS-Feeds und andere Inhalte liest man besser auf einem anderen Gerät oder konvertiert diese ebenfalls mit Calibre.
Gekaufte Amazon E-Books werden tatsächlich sofort innerhalb von 60 Sekunden an den Kindle gepusht.

Zufrieden? Definitv ja.

Das oben verwendete Bild stammt von zonebattler.net aus dem Blogartikel "Das Kindle am Manne".

SSL/TLS

SSL steht fuer Secure Socket Layer und beschreibt eine Technik um sichere Verbindungen herzustellen. Der aktuelle Name ist daher auch Transport Layer Security (TLS). Der Einfachheit halber will ich hier trotzdem die Bezeichnung SSL benutzen.
SSL benötigt zum Aufbau einer verschlüsselten Verbindung zu einem Server dessen öffentlichen Schlüssel. Die Daten können dann nur vom Server mit seinem privaten Schlüssel wieder in Klartext verwandelt werden. Dieses Prinzip bezeichnet man als Public-Key-Verfahren.
Bei HTTPS wird dem Browser, welcher die Verbindung zu einem Webserver aufbauen will, dieser Schlüssel in Form eines X.509 Zertifikats zur Verfügung gestellt. Dieses Zertifikat enthält im Regelfall neben dem Schlüssel noch die Domain, eine Gültigkeit sowie mehr oder weniger Informationen über den Aussteller und Inhaber.

Zertifizierungsstellen

Dieser Schlüssel löst zwar das Problem der Verschlüsslung, verhindert aber nicht zwangsläufig einen Man-In-The-Middle Angriff. Ist ein Angreifer in der Lage den Datenverkehr mitzulesen und zu verändern, kann er bei der Übertragung des öffentlichen Schlüssels diesen durch einen eigenen ersetzen. Danach ist die Verbindung zwar gesichert, der Kommunikationspartner ist allerdings nicht der eigentliche Zielserver, sondern der Angreifer. Es muss also sichergestellt sein, dass man wirklich das Zertifikat des Servers erhalten hat. Ein Zertifikat kann allerdings für beliebige Domains mit beliebigem Inhalt selbst erstellt werden, man sieht ihm nicht direkt an, ob es echt oder falsch ist.

Zu diesem Zweck gibt es das Prinzip von Zertifizierungsstellen, sogenannten CAs (Certificate Authorities). Die Idee dahinter ist, dass man einer bestimmten CA vertraut und damit auch den von ihr ausgestellten Zertifikaten. Um zu prüfen ob ein bestimmtes Zertifikat auch wirklich von dieser CA ausgestellt wurde benötigt man zum Vergleich deren Root-Zertifikat. Ein Browser enthält daher eine lange List an Root-Zertifikaten von verschiedenen Unternehmen. Diese Zertifizierungsstellen haben sich verpflichtet die in ihren Zertifikaten enthaltenen Daten zu prüfen. Dabei sollte zum Beispiel nur der Inhaber einer Domain sich ein Zertifikat für diese ausstellen lassen können.

Wer bist du wirklich?

In der Praxis fangen aber genau hier die eigentlichen Probleme an. Die Liste der Zertifizierungsstellen ist in allen gängigen Browsern sehr lang. Eine CA kann ausserdem die Möglichkeit des Signierens von Zertifikaten weiter delegieren. So kann eine lange Kette an CAs entstehen, die berechtigt sind gültige Zertifikate auszustellen.
Ein anschauliches Beispiel (entliehen von Certificate Patrol) ist die Bayrische Staatsbibliothek. Deren Zertifikat wurde von der eigenen Zertifizierungsstelle ausgestellt. Der Browser vertraut dieser Stelle nur weil ihr vom Deutschen Forschungsnetz vertraut wird, dem wiederum die Deutsche Telekom vertraut. Erst deren Root-Zertifikat ist in den Browsern hinterlegt. Eine "kleine" Liste von CAs nur für Deutschland findet sich bei Netcraft. Dort findet man dann auch Nestle oder Adidas in der Liste.
Absolut sichere Systeme gibt es nicht, und so kommt es immer wieder vor, dass durch die Vortäuschung falscher Informationen oder einem Einbruch in einen Server gefälschte Zertifikate ausgestellt werden.
Für einen Browser gibt es nicht zwangsläufig einen Unterschied zwischen dem echten Zertifikat meiner Bank und einem Zertifikat, welches von einer CA in einem Land ausgestellt wurde, indem ich mich nichtmal trauen würde Urlaub zu machen. Er wird in beiden Fällen eine "gesicherte Verbindung" anzeigen.
Ein aktuelles Beispiel ist Comodo, bei dem es ein Hacker geschafft hat, sich Zertifikate für Seiten wie Google Mail und Skype zu beschaffen.
Es gibt bei SSL zwar einen Mechanismus um Zertifikate über eine Liste zu widerrufen, allerdings müssen diese Fälle auch bekannt sein.
Abhilfe schaffen zumindest teilweise verschiedene Tools.

Unterstützende Tools

Perspectives

Perspectives ist ein Firefox und Chrome Plugin, um sich auch vor solchen Angriffen zu schützen. Die Idee dahinter ist es, beim Aufbau einer gesicherten Verbindung einen dritten Server nach der Checksumme des Zertifikats zu fragen und diese zu vergleichen. Der dritte Server ermittelt dann über seine eigene Verbindung die Checksumme. Ist diese unterschiedlich, ist von einem Man-In-The-Middle Angriff auszugehen, das heisst ein Angreifer hat sein eigenes gefälschtes Zertifikat in die Verbindung eingeschleust. Ausserdem werden die Checksummen auf dem dritten Server gespeichert. Dadurch wird es möglich zu prüfen ob sich das Zertifikat des Servers erst vor kurzem geändert hat.
Die Perspectives Entwickler betreiben ein kleines Netzwerk von sogenannten Notary Servern die vom Browserplugin abgefragt werden. Bekommt man von Google Mail dann plötzlich ein neues Zertifikat, obwohl die Notary Server eine andere Version kennen, gibt das Anlass zur Sorge. Zusätzlich gibt es fuer den Datenbestand der gecachten Checksummen auch ein Webinterface.
Durch diese Art der Anfragen ist natürlich nachvollziehbar, welche gesicherten Seiten ich besucht habe. Die Policy der Notary Server legt dabei viel Wert auf Datenschutz und verspricht die IP Adressen der Nutzer nicht zu speichern. Wer trotzdem lieber einen eigenen Notary Server betreiben moechte kann das mit der quelloffenen Python Server Software tun.

Certificate Patrol

Ein anderes Firefox Plugin welches den Umgang mit SSL sicherer macht ist Certificate Patrol. Es speichert einfach die Zertifikate der besuchten Seiten. Ändert sich danach etwas am Zertifikat zeigt Certificate Patrol diese Änderung zum ursprünglichen Zertifikat an.
Benutzt die eigene Bank dann plötzlich ein Zertifikat aus dem Iran, sollte man sich überlegen ob man sein Onlinebanking nicht verschiebt.
Auch auf weitere Unstimmigkeiten weist Certificate Patrol hin.

Fazit

Es gibt leider keine pauschale Sicherheit. Der gern propagierte Hinweis, "Achten sie auf das grüne Schloss in der Adresszeile des Browsers", bedeutet leider nicht automatisch eine sichere Verbindung. SSL ist eine Lösung für diese Sicherheitsprobleme, in der Praxis funktioniert diese Lösung allerdings nicht so ohne weiteres, zumindest nicht ohne sich mit der Thematik auseinandergesetzt zu haben. Man darf gespannt sein, was fuer Alternativen in den nächsten Jahren auf uns zukommen.
Im Moment hilft nur "Kopf einschalten".

Um diese Funktion nutzen zu können, wird als Empfänger anstatt des Namens einfach eine E-Mail Adresse angegeben. Der Empfänger enthält dann eine Nachricht von Facebook mit einer zufällig generierten Absenderadresse, falls der Absender nicht schon das Facebook E-Mail Feature nutzt.

Beim Pflegen des eigenen Profils auf Facebook hat man außerdem die Möglichkeit eine oder mehrere E-Mail Adressen zu hinterlegen. Für jede Adresse lassen sich die üblichen Privatsphäre Einstellungen setzen: "Öffentlich anzeigen", "Nur Freunden anzeigen", "Nur mir anzeigen". Zusätzlich kann man die Adresse vor einer Liste von "Freunden" verstecken.
Diese Einstellungen greifen aber scheinbar nur auf der Info Seite des Profils.

Kenne ich eine E-Mail Adresse und möchte den dazugehörigen Facebook Account herausfinden muss ich nichts weiter tun, als von Facebook aus an diese Adresse eine Nachricht zu schicken. Danach wird in der Liste der gesendeten Nachrichten direkt das Facebook Profil angezeigt, bei dem diese Adresse hinterlegt wurde.
Dabei werden die Privatsphäre Einstellungen völlig ignoriert. Egal ob die Einstellung "E-Mail Adresse nur mir anzeigen" gesetzt ist oder explizit vor bestimmten "Freunden" versteckt, der Verlauf zeigt mir immer das zugehörige Profil.

Dabei ist es egal ob ich mit dem Besitzer des Profils befreundet bin oder nicht: Kenne ich die E-Mail Adresse finde ich das passende Profil dazu.

In meinen Augen ist dieses Verhalten definitiv ein Fehler der gefixt werden sollte.
Mir selbst war dieser "Fehler" bisher noch nicht bekannt, im Netz konnte ich dazu ebenfalls nichts finden.
Hat da jemand mehr Infos?

Einen passenden Kontakt sucht man bei Facebook scheinbar vergeblich. Eventuell ist das Verhalten ja so gewünscht oder schon länger bekannt.
Ich bezweifle allerdings eine Antwort über das "Suggestions"-Formular zu erhalten:

"Note: While Facebook welcomes any suggestions and feedback you submit using this form, we are unable to respond to them directly. All suggestions are governed by our terms (see SRR 2.5)."

Ein Beispiel ist Neal Gafters Posting auf der Project Lambda Mailingliste "A reminder of Project Lambda's scope". Hier merkt Neal im April an, dass eigentlich schon im Juni laut Roadmap ein "feature complete" JDK 7 da sein muss.

Mark Reinhold hat dann Anfang September in seinem Blog unter "Re-thinking JDK 7" das Problem angesprochen und zwei weitere Vorgehensweisen diskutiert:

• Plan A wäre ein Release von Java 7 wie geplant, allerdings erst 2012.
• Plan B ist Java 7 mit den bereits vorhanden Features (also ohne Closures, Jigsaw und teilweise Coin) Mitte 2011 zu veröffentlichen und die restlichen Features im JDK 8 Ende 2012 unterzubringen.

Die meisten Kommentare befürworten Plan B, was seit dem 20. September mit "It’s time for … Plan B" bestätigt ist.

Welche Features landen jetzt aber in Java 7, welche in Java 8? Hier also ein kleines Update um meinen Artikel "Java 7 Features" zu ergänzen.

Die Featureliste wurde inzwischen von Reinhold geupdatet, was noch fehlt ist ein tatsächlicher Zeitplan für die Milestones. Ein paar ursprünglich nicht enthaltene Punkte sind inzwischen ebenfalls dazu gekommen.

Hier die Änderungen für das JDK 7, welches nun also hoffentlich Mitte 2011 erscheinen wird:

Sprachfeatures

• Project Coin wird in Java 7 enthalten sein, allerdings ohne Unterstützung der Sprache für Collections. Wenn ich die Beschreibung allerdings richtig interpretiere, ist "improved exception handling (multi-catch)" nun doch enthalten.

I/O and Networking

• NIO .2 wird mit einem Provider für .zip- und .jar-Files kommen.
• Unter Windows wird in Zukunft der Windows Vista IPv6 Stack bevorzugt benutzt.
• Ausserdem wird TLS 1.2 verfügbar.

Internationalization

• Unicode wird nicht wie geplant in der Version 5.1, sondern in Version 6.0 unterstützt.
• Ausserdem wurde die Unterstützung von Locales verbessert.

Zusätzlich findet dann noch JDBC 4.1 seinen Weg in den Release.

Für Ende 2012, also für Java 8, sind jetzt folgende Punkte geplant:

• JSR 294 + Jigsaw,
• Lambda (Closures),
• "Annotations on Java Types" (JSR 308),
• das Swing Application Framework (JSR 296) und die Swing Datepicker Komponente.
• Neu ist hier noch "Language support for collections".

Damit bleiben als JDK 7 Merkmale auf der Sprachseite vor allem NIO 2 und Project Coin. Auf der Seite der VM ist das wohl wichtigste Merkmal "Invoke Dynamic", um die Performance für Scriptsprachen wie Scala zu verbessern.

Ich würde mir für die Zukunft von Java einen "Date-Driven" Releasezyklus wünschen. Hier wäre dann klar, in einem festen Zeitraum kommt ein neues Release welches alle fertigen Features enthält. OpenBSD fährt damit zum Beispiel sehr Erfolgreich. Aber warten wir einfach ab, wie sich Java unter Oracle entwickeln wird.

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.

Da Java 7, Codename Dolphin, zum Ende des 2. Quartals mit dem letzten Milestone angekündigt ist, habe ich mir ein wenig Zeit genommen um die angekündigten Features vorzustellen. Ein Überblick über die zehn Milestones selbst ist auf der Projektseite zu finden.

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!