Thema der Woche: Collection-API-Erweiterungen

Die Java-Collection API bietet grundlegende Sammlungen, aber es gibt immer noch Bedarf an mehr. Drei Bibliotheken stechen hier besonders raus:

Lese etwas über die Projekte. Beantworte folgende Fragen:

  • Welche neuen Datenstrukturen enthalten Google Collections?
  • Welche Autoren arbeiten an Google Collections?
  • Welchen Sinn ergeben folgende Szenarien: new ReferenceMap(WEAK, STRONG), new ReferenceMap(WEAK, WEAK), new ReferenceMap(STRONG, STRONG)?
  • Was kann man mit der Apache-Klasse ExtendedProperties machen?
  • Wofür sind die Typen in org.apache.commons.collections.functors nötig und wie verwendet man sie ? Haben Transformer damit etwas zu tun?
  • Warum spricht Javolution an vielen Stellen von "hard real-time compliant"?
  • Bewerte den Benchmark http://javolution.org/doc/benchmark.html.

Open Source Docking Frameworks

http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks gibt einen Überblick über Docking-Frameworks:

Name Development Licens Size Comments
MyDoggy active LGPL only jar’s: 0.5 MB
NetBeans active CDDL/GPL 4.6 MB (platform.zip)
XUI active MPL 1.6 MB (XUI-jdk15.zip)
JDocking inactive CDDL 1.3 MB (v0.8.zip) the docking part
of netbeans
JRichClient active GPL heavy development derivation of flexdock
FlexDock inactive community although
there is a new version (bugfix)
MIT only jar’s: 0.5 MB
Sanaware active GPL or Commercial full zip 0.3MB
InfoNode last version January 2007 GPL
VL Docking one year old – inactive? CeCILL/GPL
Eclipse active CPL or EPL ? only swt (?)
Docking Frames active LGPL 2.1 0.7 MB

Thema der Woche: Collection-API

Die Collection-API enthält grundlegende Sammlungen für Listen, Kellerspeicher, Assoziativspeicher. Gehe über alle Operationen der folgenden Schnittstellen:

Finde je ein Beispiel für keySet(), retainAll(), toArray(), headSet().

Welche Implementierungseigenschaften haben die folgenden Klassen:

Fülle eine WeakHashMap mit sovielen neuen java.awt.Point-Objekten, bis es einen OutOfMemoryError gibt. Fange diesen ab und gib die Größe der WeakHashMap aus.

Laufe zum Verständnis der Implementierung folgende Szenerien im Debugger ab:

  • Ein Element wird in die HashMap eingefügt, dann erfragt.
  • In eine LinkedList bzw. ArrayList werden einige Elemente eingefügt, dann nach ihrer Position erfragt und gelöscht.

Buchkritik: Hardcore Java

Robert Simmons. O’Reilly. ISBN 0-596-00568-7. März 2004. 344 Seiten
Warum tut mir O’Reilly das an? Ich setze es ohne Bedenken auf Platz 1 in der Liste der Java-Bücher, die einen völlig verfehlten Titel tragen. Im Vorwort wird noch groß verkündet: „We’re talking about difficult but extremely powerful and useful programming techniques like reflection, advanced data modeling, advanced GUI design, and advanced aspects of JDO, EJB and XML-based web clients. This unique book reveals the true wizardry behind the complex and often-mysterious Java environment.“ und dann kommt nur Anfängerstoff und nix von JDO, EJB oder XML. Dafür umso mehr Kindergartenthemen: Jede Klasse ist von java.lang.Object abgeleitet, ein „if“ verträgt auch komplexe Anfragen mit ZWEI Bedingungen oder dass es einen ?-Operator gibt. Echt Hardcore! Des Weiteren deklariert Felder in umständlicher Syntax int[] AN_ARRAY = new int[] {1, 2, 3, 6, 9, 18, 36}; statt einfach nur int[] AN_ARRAY = {1, 2, 3, 6, 9, 18, 36}; Und schließlich 30 Seiten Auseinandersetzung von final. Die Namen der Color-Konstanten sind klein statt groß (gibt es „erst“ seit Java 1.4) geschrieben, und warum der Autor in dem Calendar-Beispiel ausdrücklich nach GMT fragt, ist ebenfalls sonderbar, denn für das Beispiel spielt das überhaupt keine Rolle:

private Date creationDate = Calendar.getInstance(TimeZone.getTimeZone("GMT")).getTime( );

Im nächsten Kapitel über immutable kommt natürlich der Hinweis auf String (immutable) und Point, Date, StringBuffer (nicht immutable), aber wertvolle Hinweise, etwa das immutable-Typen die Entwicklung von multitheaded-Anwendungen massiv erleichtern und immutable Objekte gut in einen Pool passen (wie einige Wrapper-Objekte in Java 5) werden unter den Teppich gekehrt. Immerhin erwähnt er die Unmodified-Wrapper. Weiter zum nächsten Hardcore-Thema, der Collection-API. Mr. Simmons schreibt: „…code is an example of a good interface-based technique:“

public class SomeClass {
HashSet someSet = new HashSet( );
protected Set someMethod( ) {
return this.someSet;
}
}

Der Objekttyp von someSet sollte wohl Set statt HashSet sein. Und warum ist in dem Beispiel die Methode gerade protected? Und someSet paketsichtbar? Da steckt vermutlich Hardcore Java Design-Erfahrung im Code. Na ja, dann hakt das Kapitel noch mal eben alle Hardcode-Collection-Klassen ab. Dass Robert fail-fast von Iteratoren erklärt, ist super, aber dann der nächste Rückschlag bei set.add(new String("p->" + element)). Was soll denn das heißen? Das nächste Kapitel heißt Exception-Handling (in welchem Java-Einführungsbuch steht das bitte schön nicht?) und der Hinweis, dass finally eine gute Stelle ist, um Datenbankverbindungen zu schließen. Das folgende Kapitel ist noch viel härter. Es geht um innere Klassen. Jetzt ist es an der Zeit, sich jeden Satz ganz genau anzuschauen und sich hoch zu konzentrieren. Radio aus, Fernseher aus, Computer aus. Weiter zum nächsten Hammerthema – Konstanten und Internationalisierung. Dass Robert auch Klammern kennt, zeigt er in Anweisungen wie dieser:

double area = (Math.pow(radius, 2) * PI);

(Wie wäre es stattdessen einfach mit radius * radius * 2? Oder wollte er ein Beispiel für größtmöglichen Rechenaufwand leisten?) Um vielleicht ungenauen Pi-Belegungen von Sun über Math.PI vorzubeugen, ist es auch sinnvoller, gleich selbst PI vorzubelegen: public static final double PI = 3.141;. Ist viel viel besser! Im Kapitel werden auch Bit-Felder vorgestellt inklusive der Bit-Operatoren. Bei den anschließenden Aufzählungen und Konstanten-Objekten baut der Autor dann erst einmal das Java 5 enum nach, bis er schlussendlich im letzten Kapitel auch zu Java 5 kommt. Dann kommt aber doch noch ein interessanter Absatz über readResolve() bei der Serialisierung. Immerhin hat Robert verstanden, dass es Klassenlader gibt: „You may think that since the constant object is final and static, this will guarantee that only one instance of each constant object will be in memory. I used to think the same thing until I was blindsided by a vicious bug in a genetic research system.“ Impressive! Im 8. Kapitel geht’s um Datenmodellierung. Kein Java-Thema und auch nur ein paar Seiten. Der Ansatz: „Unterstreiche alle Nomen und du hast Klassen, unterstreiche alle Verben und du hast Methoden“ darf auch nicht fehlen. So hat Robert sicherlich große Enterprise Systeme modelliert. Kapitel 9 hat Reflection zum Thema und etwas zum java.beans Paket. Seine Lust, an alle möglichen finalen Variablen auch final dranzuschreiben, sinkt. Kapitel 10 kommt auf Proxies zu sprechen, und dass die bei CORBA und RMI vorkommen. Nachdem ein selbstgebauter Proxy sich vorstellen darf, kommt es doch noch zu Einsatz vom InvocationHandler/Proxy. Jetzt wird es langsam interessant. Kapitel 10 spricht von schwachen Referenzen. Er implementiert ein

public class WeakHashSet extends AbstractSet implements Set

(warum steht hier implements Set?) und schreibt einen Weak-Listener. Solch ein Konstrukt ist insbesondere in Swing-Anwendungen sehr nützlich, doch hier hätte ich den Hinweis gut gefunden, dass etwa die OpenIDE, also NetBeans, hier schon etwas anbietet. Wo jetzt andere „Hardcore“-Bücher einsteigen ist seines, oh schade, schon zu Ende. Das war eigentlich das letzte Kapitel! Denn Kapitel 12 ist das Abschlusskapitel mit Java 5 und geht auf die Neuerungen ein. Doch seien wir ehrlich: Harte Nüsse wie Generics lassen wir uns viel lieber von einem echten Crack, von Joshua Bloch, in seinem Buch erklären. Dann müssen wir uns nicht Beispiele wie dieses hier anschauen:

class SomeClass<Type> {
Type value = null;
public Type getValue() {
return this.value();
}
public void setValue(final Type value) {
this.value = value;
}
}

Typvariablen sollten immer nur aus einzelnen Großbuchstaben bestehen. Bei einer Deklaration wie Type getValue() sieht sonst Type wie ein ordinären Java-Typ aus. Und warum wird value mit null initialisiert. Das ist doch klar, dass die JVM das mit null belegt. Was zeigt das Buch? Immerhin das O’Reilly den Mut hat, die schlechten Bewertungen auf der Webseite stehen zu lassen und nicht zu löschen. Meine Hochachtung. Bei Amazon sind die Bewertungen aber noch ehrlicher. Mut wird O’Reilly erst dann wirklich beweisen, wenn sie a) den Titel umformulieren, b) sich einen neuen Autor suchen, der das Buch umschreibt bzw. erweitert oder c) – die beste Option für jetzt – das Buch aus dem Sortiment nimmt. 4 Jahre nach Erscheinen wird’s Zeit dafür.

Buchkritik: JavaScript: The Good Parts

Douglas Crockford. O’Reilly. ISBN 978-0-596-51774-8. Mai 2008. 170 Seiten

In meinem Alltag habe ich wenig mit JavaScript zu tun (von meinem Visual Foxpro nach JavaScript-Konverter einmal abgesehen), sodass mir das Buch gerade recht kam, um meine JavaScript-Kenntnisse zu vertiefen. Es ist sicherlich nicht für absolute Anfänger geschrieben, doch für Leser mit Grundkenntnissen gut geeignet, tiefer in die Sprache einzusteigen. Techniken wie den Prototyp-Ansatz der Objektorientierung beschreibt Douglas sehr genau, sicherlich etwas zu detailliert für diejenigen, die nur  mal eben" JavaScript für die Webseite einsetzen möchten. (HTML und DOM spielen kaum eine Rolle. JavaScript wird eher als allgemeine Programmiersprache behandelt und weniger als  Webseitensprache".) In seine Beispielen finde ich teilweise den Rückgriff auf Variablen und Methoden aus vorangehenden Beispielen etwas irritierend. Zum Beispiel kommt seine selbstgebaute beget()-Funktion immer wieder vor, doch ohne einen Verweis für Leser, die erst in der Mitte einsteigen und diese Funktion nicht kennen. Seiner Argumentation beim Inkrement-/Dekrement-Operator ++, –, "In my own practice, I observed that when I used ++ and –, my code tended to be too tight, too tricky, too cryptic. So, as a matter of discipline, I don’t use them any more. I think that as a result, my coding style has become cleaner." bei den Bad-Parts kann ich nicht folgen, doch sonst erscheinen mit die Bad- und Awfull-Parts recht sinnvoll ausgewählt. Der
Unterschied zwischen == und === enthält tolle Beispiele; Begründungen für die Auswertung wären allerdings schön.

'' == '0'          // false 
0 == ''            // true
0 == '0'           // true
false == 'false'   // false
false == '0'       // true
false == undefined // false
false == null      // false
null == undefined  // true
' \t\r\n ' == 0    // true

Im Anhang stellt der Autor JSLint vor, ein Tool zum Testen der Codequalität von JavaScript-Programmen. Das ist zwar nett, doch hätte

ich freie JavaScript-Bibliotheken (wie etwa Prototype) lieber gesehen. Das Kapitel 4 (Functions) gibt’s online.