Buchkritik: Die Java-Syntax, Michael Kofler

Der Autor ist jedem ein Begriff, der in der Unix-Welt einmal unterwegs war: Wo die Java-Insel das Standard-Werk für Java ist, ist Koflers Linux-Buch (jetzt auch bei Galileo) DAS Buch für das Open-Source Betriebssystem. Nicht vielen bekannt ist, dass Kofler neben Linux auch noch weitere Bücher verfasst hat, insbesondere als eBook. Eines davon handelt über Java und trägt den kurzen Titel „Die Java-Syntax“. Hier kommen Assoziationen zur Java Language Specification auf, doch mit einer formalen Beschreibung der Sprache hat dieses eBook überhaupt nichts gemeinsam — es ist eher eine allgemeine Einführung in Java und einigen Bibliotheken, wie Date/Time, Threading und Collection. Die Beschreibung ist dabei nicht sonderlich tief und einige Begrifflichkeiten sind doch sehr ungewöhnlich, die Collection-Klassen heißen etwas Aufzählungsklassen, der Autor schreibt oft „Klasse“, wenn er „Typ“ meint, die Sprachst ist im Allgemeinen etwas ungenau und könnte präziser sein, teils irreführend wie bei „Normalerweise können Methoden nur genutzt werden, wenn vorher ein Objekt der betreffenden Klasse erzeugt wird“ klingt, als ob statische Methoden un-normal seien und abartig. Einige Aussagen zeugen von nicht sehr tiefem Java-Verständnis, etwas bei den Überschreibungsregeln der throws-Klausel, wenn Kofler über die Implementierung der Schnittstelle AutoCloseable schreibt „Sie müssen nur darauf achten, dass Sie Ihre close-Methode mit throws Exception deklarieren“. Oder wenn der Autor den Minus-Strich im Paketnamen wählt (de.meine-firma) und ein ganzes Beispiel mit Pakten, und Jar-Archiven darum aufbaut, was aber nie compilieren würde, da „-“ in Bezeichnern überhaupt nicht erlaubt ist. Zusammenfassend lässt sich festhalten, dass Kofler eine Einführung in Java gelungen ist, die aber weit hinter seinen anderen Büchern zurückbleibt. Im dem Segment der Einführungsbücher wird „Die Java-Syntax“ es daher schwer haben. Eine Kurzvorstellung vom Autor gibt es in einem Video, eine Leseprobe auf seiner Webseite. Ein Buch-Update ist geplant.

Die Java-Syntax; Variablen Operatoren Klassen Exceptions Multi-Threading Generics und Collections Lambda-Ausdrücke. Für Java 6, 7 und 8

Michael Kofler. Verlag ebooks.kofler. ISBN 978-3-902643-09-4. 216 Seiten

Buchkritik: Wicked Cool Java: Code Bits, Open-Source Libraries, and Project Ideas

Brian Eubanks; ISBN-10: 1593270615; No Starch Press; 15.11.2005; 248 Seiten
Mit dem Buch hat Brian eigentlich das gemacht, was sich jeder Autor wünscht: sich hinzusetzen und einfach mal im Artikelstil über alles zu schreiben, was einem interessiert, ohne darauf zu achten, ob das nützlich oder wichtig ist. Dafür nimmt er sich 8 Kapitel Zeit:
Chapter 1: Java Language and Core API, Chapter 2: String Utilities, Chapter 3: Processing XML and HTML, Chapter 4: Crawling the Semantic Web, Chapter 5: Math and Science, Chapter 6: Graphics and Data Visualization, Chapter 7: Multimedia and Sychronization, Chapter 8: Fun, Integration and Project Ideas. Im Grunde ist nur das erste Kapitel ein kleines Einstiegskapitel, insbesondere in die Neuerungen von Java 5, und zusammen mit dem zweiten Kapitel haben sie die Java SE selbst zum Inhalt. Das Niveau ist an Anfang niedrig und passt nicht zum Rest. Syntaktisch ist nicht immer alles sauber, so gibt es immer wieder umständliche Feldinitialisierungen wie int[] theList = new int[]{2,3,5,7}; oder java.util.Random random = new Random(); wo ich mich Frage, ob der Autor dort gerade wach war. Dann wird assert geklammert wie eine Methodenaufruf, das ist aber nur in C so, nicht in Java, wo assert ein Schlüsselwort ist und der Ausdruck nicht geklammert wird. (Macht Krüger im Buch aber leider auch so.) Leider sind auch nicht alle Beispiele konsequent auf Java 5 ausgelegt, immer wieder findet sich der Raw-Type etwa von Datenstrukturen, bei seinen verketten Listen-Implementierung oder mit verketteten Knoten wiederum fehlt ein Generic, hier steht nur Object content. An anderer Stelle im Buch gibt es den Hinweis, das ein Listing mit Generics auf der Buchseite (http://www.wickedcooljava.com/) ist, warum nicht gleich im Code? Mit Generics scheint Brian auch noch nicht so vertraut zu sein, anders kann ich mir nicht erklären, warum er eine Methode removeMatches(List<Number> aList) schreibt, denn man muss verstehen, da man so etwas nicht zum Beispiel mit einer List<Double> aufrufen kann; eleganter wäre ein Typ-Bound er Art List<? extends Number> hin. Weiter: Statt StringBuilder kommt noch StringBuffer zum Einsatz. Nicht gut gefällt mir auch der Bezug auf konkrete Klasse, statt Basistypen, etwa bei ArrayList<String> getNames(), hier würde als Rückgabe auch List oder Collection reichen. (In dem gleichen Beispiel ist auch unglücklich den Scanner auch nicht im finally zu schließen. Und getFloat() statt getDouble() zu nehmen ist auch Geschmackssache.) Bei den Farben verwendet der Autor noch die klein geschriebenen Namen also Color.blue statt Color.BLUE. Sehr geschwätzig ist auch if ( … ) { return true; } else { return false; } — das ist uncool.
Im Mittelpunkt des Buches geht es um wilde Open-Source Bibliotheken, etwa für mathematische Operationen, Textanalyse, Suche (nicht wild), semantische Netze, RDF, MIDI-Sounds. Eigentlich nichts, was man wirklich/dringend/oft bräuchte, und wenn, würde man vermutlich in ein spezielles Buch schauen. Positiv ist anzumerken, dass uns der Autor die Libs vorstellt und des Lesers Horizont erweitert. Ein Probekapitel gibt es nicht online, allerdings unter http://www.wickedcooljava.com/related.jsp eine Linkliste der Bibliotheken. April 2013

Buchkritik: The Clean Coder von Robert C. Martin

Ich mag das Buch von Robert Martin (Uncle Bob), weil es offen und ehrlich ist. Selten sagen Entwickler und Berater: „Da habe ich Mist gemacht, ich war blöd, das war dumm“. Robert ist da schonungslos und legt offen, an welchen Stellen er in seinem Leben vor die Wand fuhr. Daraus formuliert er Grundsätze, von denen wir alle lernen können. Dabei ist das Buch relativ untechnisch. Vielmehr steht der Entwickler als Mensch als soziales und mitunter selbstherrliches Wesen im Vordergrund; Coding-Tipps wie Pattern oder Idiome fehlen gänzlich. Aber das ist gut so, denn viel zu oft denken gerade Neueinsteiger, es kommt auf die coole Programmiersprache an, oder Meister der Kommandozeile zu sein. Alles falsch bzw. das ist nur ein Teil. Softwareentwicklung ist ein kollaborativer Prozess. Man muss „Nein“ sagen zu Dingen, die man nicht einhalten kann und ein „Ja“ bedeutet, ein Commitment zu machen, um verlässlich im Team zu arbeiten. So ist auch „Ja“/“Nein“ zu sagen, und die Konsequenzen zu tragen, ein zentraler Bestandteil des Buchs. Weitere Themen sind Zeiteinteilungen, Arbeiten unter Druck und immer wieder, was ein professionellen Entwickler auszeichnet: Testen, Testen, Testen. Da der perfekte professionelle Entwickler nicht geboren, sondern im Laufe der Jahre heranreift, nimmt auch diese Entwicklung im Buch Platz ein. Zentrale Themen bei Martin sind: Programmieraufgaben (was man selbst tun kann) und Mentoring (was die Umgebung/Arbeitgeber tun kann). Wer schön länger im Geschäft ist muss das Buch nicht lesen, denn jeder wird sich dort wiedererkennen; jeder angehende Softwareentwickler sollte das Buch aber lesen und einen Eindruck gewinnen, worauf man sich einlässt und was es heißt, professionell zu arbeiten.

http://www.amazon.de/Clean-Coder-Professional-Programmers-Paperback/dp/B006V37B1G/ref=sr_1_5?s=books&ie=UTF8&qid=1355651332&sr=1-5%20&tag=tutego-21

Buchkritik: XDoclet in Action

Craig Walls, Norman Richards. Manning. ISBN 1-932394-05-2. 2004. 600 Seiten

XDoclet selbst stammt von Rickard Öberg, der auch das Vorwort für das Buch geschrieben hat, aber Craig (war selbst XDoclet Committer) und Norman leisten gute Arbeit, XDoclet vollständig zu beschreiben – Öberg hat Korrektur gelesen. Der Ursprung des Buches liegt laut Autoren in der Motivation XDoclet selbst besser zu verstehen, doch die Autoren sind allgemein und gründlich genug, damit Leser unterschiedlicher Bildungsschichten etwas davon haben. (Allerdings hört es in der Tiefe dann irgendwann einmal auf, das hat aber nichts mit XDoclet selbst zu tun, sondern etwa rund um EJB-Assoziationen.) Das erste Kapitel führt die Grundlagen von Codegenerierung ein und wie XDoclet ins Bild passt. Aktiver wird von passiver Codegenerierung unterschieden, unterschiedliche Ursprungsformen werden geschrieben und diskutiert ob und wie XDoclet ins eigene Projekt passt. Kapitel 2 ist technischer und führt Tags und Ant-Tasks ein, um Generierung von Todo-Listen zu zeigen. XDoclet Tasks und Subtasks werden kurz vorgestellt. Es folgt eine Kurzeinführung in Templates für die Codegenerierung, etwas detailliert vielleicht zu Anfang, aber in Ordnung. Im späteren Kapitel kommt das noch sehr genau zur Sprache. Es folgt das Konzept der wichtigen Merge-Points und das Kapitel schließt mit dem Bigger-Picture und der Feststellung, dass Metadaten nur an einer Stelle stehen sollte und Redundanzen minimiert werden müssen. Es folgt der zweite Abschnitt, der sich konkret mit dem EJB-Doclet, und XDoclet fürs Web beschäftigt. Kapitel 3 ist für die klassischen J2EE 1.4 Entwickler das wichtigste Kapitel. Das Beispiel ist mit einem Weblog gut und anschaulich gewählt. Dass die Property im UML-Diagramm allerdings „test“ heißt ist ein Fehler; es sollte „text“ heißen. Alle zentralen Tags werden an Beispielen gezeigt, also wie ein Session-Bean getagt wird, eine Entity-Bean und die Beziehungen der Entiy Bean aufgebaut, und wie eine Fassade und Utility-Klasse generiert werden und was im Prinzip darin steckt (Quellcode wäre gut gewesen hier). Es folgt die Generierung eines Value Objects (VO) was die Autoren hier mit dem Data Transfer Object (DTO) gleichsetzen, aber heutzutage trennt man die Konzepte. Matcher für unterschiedliche VOs kommen zur Sprache genauso wie Aggregationen und Composites, also das auch die assoziierten Objekte einer CMP mit in das VO aufgenommen werden. Die Beschreibung könnte allerdings etwas detaillierter sein und es wäre eine Bereicherung, wenn die Autoren alle Szenarien, also 1:1, 1:n, n:m einem Bi- und einmal Unidirektional durchgespielt hätten. Das Kapitel schließt mit den Sicherheits-Tags, Finder/Selector und einer Übersicht, welche Dateien XDoclet für das Blog-Beispiel generiert, Transaktionsattributen, DAOs für BMP und Message Driven Beans. Gewünscht hätte ich mir noch eine Zusammenfassung mit einer Gegenüberstellung der Tags mit dem Ergebnis im Deployment-Deskriptor bzw. Quellcode. Kapitel 4 widmet sich der Web-Tier. Der Ant-Task webdoclet wird vorgestellt und es beginnt mit dem Tag für Servlets, Filter, Listener und JSP-Tag-Libs, damit die web.xml erstellt wird. Das Beispiel führt die Idee des Blogs fort. Die Qualität der Quellcodebeispiel ist relativ gut wobei mir bei Listing 4.7 auffällt, dass die Autoren folgendes für doEndTag() schreiben:

try {

if(date != null) {

SimpleDateFormat formatter = new SimpleDateFormat(format);

pageContext.getOut().write(formatter.format(date));

}

} catch (IOException e) { }

return EVAL_PAGE;

}

Die IOException zu schlucken ist vielleicht nicht so toll (in den übrigen Beispielen wird schön geloggt) und ich frage mich, warum der String format zwar in der Objektvariablen gehalten wird, aber warum nicht gleich SimpleDateFormat (und dann auch vom Basistyp DateFormat, der für format() reicht). Möglicherweise wissen die Autoren das die java.util.Format-Klassen nicht Thread-sicher sind, vergessen aber, dass die Tag-Objekte nicht wie die Servlet-Klassen geteilt werden, sondern der Servlet-Container wegen des Zustands der Tag-Objekte immer neue aufbaut (sogar bei jedem Request!) und es somit keine parallelen Zugriffe auf doEndTag() gibt. Es folgt das 5. Kapitel, welches die XDoclet-Unterstützung für Struts und Web-Works vorstellt. Es werden zwei wichtige Merge-Points für web.xml vorgestellt, dann folgend Details über die Struts-Actions und Validatoren und WebWork, bei dem sich die Aussage „Another web-layer framework that is gaining in popularity is OpenSymphony’s WebWork“ nicht bewahrheitet hat. Kapitel 6 springt dann wieder in die Welt der Application-Server und beschreibt Tags für die Container-spezifischen Deployment-Deskriptoren exemplarisch an JBoss und WebLogic. Das beendet den zweiten Abschnitt und der dritte Abschnitt beginnt mit spezielleren Technologien Hibernate/JDO/Castor, der alten Axis-Version, JMX, Mock-Objekte und Portlets. Hibernate wird nicht allzu tief vorgestellt, was ein echtes Manko ist, denn die XDoclet-Unterstützung ist/war perfekt und Entwickler griffen gerne zu XDoclet, um sich die .hbm.xml generieren zu lassen. Hier muss dann die Dokumentation aus dem Anhang oder der Webseite aushelfen, denn das Buch kommt über ein paar einfache Properties und Relationen nicht hinaus, denn sofort geht es zu JDO und dann Castor JDO, Castor XML. Es folgen Web-Services mit Apache SOAP (dem Vorgänger von Axis 1) und Axis 1 dann in Kapitel 8 und wie XDoclet die Deployment-Deskriptoren generiert. Es folgt der Hinweis, das für die Serializer und Deserializer keine Tags existieren, stattdessen ein Merge-Point genutzt werden muss. Damit schließt das Kapitel und das Kapitel 9 widmet sich einer Kurzeinführung zu JMX und kommt dann zu Generierung von MLET-Dateien und der unterschiedlichen Descriptoren für Container wie JBoss oder MX4J. Kapitel 10 entfernt sich komplett von Java EE-Technologien und geht auf Mock-Objekte ein; eine Schnittstelle Automobile wird getaggt und XDoclet erzeugt eine Klasse AutomobileMock. Warum die Autoren allerdings eine Schnittstelle mit 15 (!) Operationen deklarieren und nicht 1 und dann auch nicht bei Ihrem Blog-Beispiel bleiben bleibt im Dunkeln. Die 15 Operationen führen jedoch dazu, dass die AutomobileMock.java über 700 Zeilen dick ist und nicht abgebildet werden kann. Anschließend zeigt ein Beispiel wie im JUnit-Testfall das Mock-Objekt initialisiert und genutzt wird. Da XDoclet kein bekanntes Mock-Framework nutzt, ist die Bedeutung der Lösung gering. Kapitel 11 würde eigentlich viel besser an die Java EE Technologie passen, denn es beschreibt Portles und welche XDoclet-Tags es für welche Einträge im Deployment-Deskriptor portlets.xml gibt. Der letzte Abschnitt, beginnend mit Kapitel 12, geht tiefer in die Architektur von XDoclet ein und beschreibt, wie das Templating funktioniert und eigene Tags und Tasks entwickelt werden. Der 4. Abschnitt nimmt viel Raum ein. Zunächst stellte Kapitel 12 heraus, warum man sich mit Codegenerierung beschäftigten sollte. Es beginnt mit der Aggregation, also dem Sammeln von Informationen und einem einfachen Template; dabei werden die Grundelemente vom .xdt-Format der XDoclet-Template-Dateien vorgestellt. Es folgt die Transformation mit einem Factory-Generator – das ist anschaulich und für jeden gut verständlich. Danach spielen die Autoren den Template-Mechanismus für einen Command-Konfiguration weiter und stellen Tags vor um alle Attribute aus den Java-Klassen, etwa Felder, Konstruktoren auszulesen; das ganze erinnert ein wenig an Reflection. Es folgt ein eigener Content-Tag-Handler und Body-Tags, denn nicht alle lässt sich in XDoclet so einfach umsetzen; es ist wie die JSTL unter Verbot von Skriptlets: Nur lesen ist einfach, aber Zwischenzustände halten wird schnell unleserlich. Das Kapitel schließt mit einem Abschnitt, danit eigene Tags wie eingebaute aussehen – Ant steht naturgemäß im Mittelpunkt. Im Kapitel 13 folgenden XDoclet-Erweiterungen und Tools, worunter die Autoren die IDE-Integration in IntelliJ und Eclipse (mit JBoss IDE) meinen und das MDA-Werkzeug AndroMDA und Middlegen, was Datenbanken ausliest und aus dem Schema XDoclet-versehene EJB-CMP-Klassen (oder JDO-Klassen) generiert. Abschließend gibt der Anhang A eine ausführliche Installationsanleitung für Ant und XDoclet und Anhang B listet die Tasks/Subtasks auf, Anhang C gibt auf über 100 Seiten eine schöne Übersicht über alle XDoclet-Tags, Anhang D die XDt-Template-Syntax und zu aller letzt philosophiert Anhang E über die Zukunftsaussichten von XDoclet. So kommt zu Sprache, dass es XDoclet 2 mit einer neuen Code-Generierungs-Engine Generame gibt sowie einem Code-Templating der auf Jelly bzw. Velocity zurückgreift. Dass XDoclet durch Annotationen komplett sterben wird konnten die Autoren 2004 nicht ahnen; nur ein Jahr Mitte 2005 später bleibt die Uhr bei Version 1.2 stehen. Was ist also meine Zusammenfassung für das Buch? Wer mit XDoclet noch in alten Projekten zu tun hat, der wird dieses Buch mögen. Es ist ausführlich und gut und die Beispiele sind hervorragend, fast immer durchgehend und zu abgehoben. Der Quellcode im Buch ist mehrheitlich in Ordnung, es gib immer wieder Kleinigkeiten, die mich an den Allgemeinen Java-API Kenntnissen und Wissen um die gesetzten Java-Idiomen der Autoren zweifeln lassen. Bei:

String logLevel = config.getInitParameter("LogLevel");

if(logLevel.equals("debug"))

muss man sich fragen, ob man wirklich auf einen potenziellen null-Kandidaten equals() aufrufen möchte – die Variante "debug".equals(logLevel) ist da eigentlich angebrachter. Im Listing 7.9 ist eine public Standardkonstruktor als einziger Konstruktor ohne JavaDoc aufgeführt; die paar Zeilen hätte sich die Autoren auch schenken können und im gleichen Beispiel sind die Parametervariablen nicht prickelnd:

public void setEmail(String string) { email = string; }

public void setId(String string) { id = string; }

Das gleiche auch für Property name und owner. Vom Beispiel 8.1 bin ich enttäuscht. Die String-Variable VOWELS ist mit "AEIOUaeiou" vorbelegt und dann folgt in der Methode:

Character c = new Character(word.charAt(i));

if(VOWELS.indexOf(c+"") >= 0)

endBuffer.append(c.charValue());

Hier Character-Objekte aufzubauen ist grober Unfug, ein

char c = word.charAt(i);

if(VOWELS.indexOf(c) >= 0)

endBuffer.append(c);

hätte es voll getan (die String#contains(CharSequence)-Methode gab es damals noch nicht, sie wurde erst mit Java 5 eingeführt). In Listing 9.2 im JMX-Kapitel ist die Variable home ohne Sichtbarkeitsmodifizierer, aber private final wäre korrekter. Oder Listing 11.5 im Portlet-Kapitel:

private static String[] states = { … }

private static Set stateSet = new HashSet();

static {

stateSet.addAll(Arrays.asList(states));

}

Was soll das? Zunächst kann states und stateSet final sein, aber davon abgesehen ist der static-Block überflüssig denn der Konstruktor von HashSet nimmt gerne eine Collection an. Besser also – und auch großgeschrieben, wie es die Autoren bei den anderen static-Variablen auch gemacht haben – wäre:

private final static Set STATE_SET = new HashSet( Arrays.asList(states) );

Es fallen weiterhin Kleinigkeiten und Flüchtigkeitsfehler auf, etwa bei

public class Widget {

Widget() {

}

// … widget methods …

}

in dem der Konstruktor nicht public ist, die Klasse aber schon, und im Folgenden

public Widget new Widget() {

return new Widget();

}

was mit dem Leerzeichen auf keinen Fall ein gültiger Methodenname ist. In Kapitel 12 steht in Tabelle 12.1 bei „Field“ in der rechten Zelle „Working with method fields“, aber den Autoren ist beim Copy/Paste wohl das „method“ durchgerutscht. Dann ist ifDoesntHaveclassTag falsch geschrieben, es sollte ifDoesntHaveClassTag heißen, ein anderes Mal stimmen die Einrückungen nicht. Aber diese Kleinigkeiten kann man verzeihen und haben kein großes Gewicht. Aber die Gretchenfrage ist: Sollte man sich das Buch kaufen wenn man nicht aus einem Altprojekt XDoclet erbt? Die Antwort ist eindeutig: Nö. Statt Metadaten über JavaDoc zu setzen sind es heutzutage Annotationen der Standard. XDoclet hat den Dreh nicht bekommen, sich zu einem allgemeinen Code-Generator zu mausern. XDoclet 2 erwartet zwar die Metadaten nicht mehr zwingend in den JavaDocs, sondern kann durch seine Modulfähigkeit die Metadaten prinzipiell auch aus Annotationen lesen, aber irgendwie interessiert sich keiner dafür; Das Projekt kam nie aus der Planungsphase. Ein anderer Grund, dass XDoclet heute keine dominante Rolle mehr spielt, ist der Wegfall überflüssiger Klassen und Descriptoren aus modernen Frameworks. XDoclet machte EJB 2 angenehm, doch in EJB 3 ist XDoclet einfach nicht mehr nötig, genauso wenig wie für Hibernate oder Web-Services. Schade um das Buch, ich mag XDoclet aber seit auch Servlet 3.0 auf Annotationen setzt wird auch die web.xml zur Nussschale. Daher wird auch kein Buch-Update mehr geben und so bleiben Versionen für immer eingefroren: JBoss 3.2, Servlet 2.3, Hypersonic Database statt HSQLDB, drei MBean-Typen (es sind nun 4, da Open MBean dazugekommen ist) und MX4J lebt im Buch noch. Wie schnelllebig die IT-Zeit doch ist.

Buchkritik: Art of Java Web Development

Art of Java Web Development. Struts, Tapestry, Commons, Velocity, JUnit, Axis, Cocoon, InternetBeans, WebWork
Neal Ford. Manning. ISBN 1932394060. 2004.630 Seiten

Ford teilt sein Buch in drei Teile ein: Architektur von Web-Anwendungen, konkreten Frameworks und Best-Practices. Im ersten Teil „State-of-the-art web design“ ist von One-Page-Applikationen keine Rede und auch der Begriff „Ajax“ fällt auf den 630 kein einziges Mal; Web-Applikationen haben sich innerhalb von 5 Jahren komplett gewandelt. Die Web-Frameworks die Ford dann im zweiten Teil vorstellt sind allesamt veraltet, sodass man das Buch getrost beiseite legen kann. Und InternetBeans Express von JBuilder? Noch exotischer als WebWork! Wer noch ein Altprojekt hat, nimmt sich besser ein Spezialbuch zu dem jeweils relevanten Framework. Bei diesem alles-in-einem-Ansatz bleibt sonst zu viel auf der Strecke. Die Beispiele selbst sind gut und der Quellcodestil ordentlich, aber das Buch ist eben auf dem Stand, was 2004 gerade „State of the Art“ war. Das ist lang her, damals was noch nichts mit Ajax und Single Sign On. Das Buch hat eine Webseite bei Manning (http://www.manning.com/ford/) und Kapitel 5 (Struts 1, nützlich zum Einstieg) und 13 (Flow Handling) gibt es zum kompletten Lesen frei sowie die Quellcodes.

Buchkritik: Java Extreme Programming Cookbook

Eric M. Burke, Brian M. Coyner. O’Reilly. ISBN 0-596-00387-0. März 2003. 288 Seiten

Viele XP-Bücher konzentrieren sich auf die „menschliche“ Seite der XP-Entwicklung, aber nicht auf die Tools, die bei der XP-Entwicklung einen großen Stellewert einnehmen. Diese Lücke versucht das Buch mit einer Vorstellung der Tools und Technologien zu füllen, die Anfang 2000 von Bedeutung waren: EJB 2, JUnit 3, CVS. Dumm ist nur, dass die Technologien und Tools heute an Bedeutung verloren haben und durch neuere Produkte ersetzt wurden, sodass auch das Buch heute nicht mehr sonderlich spannend ist und als veraltet gelten kann. Java EE 5 (bzw. Java EE 6) ersetzen für Enterprise-Produkte die J2EE 1.4, JUnit 3 ersetzt heute JUnit 4, Cactus (http://jakarta.apache.org/cactus/) wird nicht mehr weiterentwickelt, und Subversion ersetzt CVS. Für ein Buch, das es nicht nur bei den Konzepten belässt, sondern auch technisch tiefer geht ein Problem. Weiterhin ist die ausschließliche Betrachtung von Open Source etwas einschränkend. (Und der Titel des Buches ist nicht „Java XP Programming Cookbook with Open Source Tools“!) Es ist zwar toll, dass Open-Source Produkte nichts kosten und auch sehr verbreitet sind, aber Hersteller wie Atlassian bieten sehr gute Projekte, die bei der XP-Entwicklung helfen. Weiterhin fehlen in meinen Augen einige zentrale Tools, und es reicht nicht, XP auf Ant, JUnit (zzgl. HttpUnit, JUnitPerf), Mocking, XDoclet zu beschränken. Hier gibt es bessere Bücher. Februar 2009

Buchkritik Pro Jakarta Commons

Harshad Oak, Apress, 1590592832, Februar 2004, 304 Seiten

Harshad Oak beschreibt in dem Buch die bekannten Jakarta Commons Bibliotheken. Nicht jede Funktion wird vorgestellt, sodass das Buch die JavaDoc nicht ersetzt. Eher versucht der Autor die Philosophie und Kernkomponenten zu vermitteln. Es gibt immer wieder komplett abgebildete Listings, die man direkt in die IDE einsetzen und mit den entsprechenden Libs im Klassenpfad direkt ausführen kann. Mich hätte gefreut, wenn hinter den println()-Zeilen gleich die Ausgabe steht, so muss nicht man immer unter das Listing schauen – das geht besser. Die Auswahl an Themen ist OK, nur sein Styleguide ist zum Teil etwas schwach, wenn er etwa Variablen iVowelCnt oder iTestLen nennt. Auch Zeilen wie

char[] aChars = new char[] { ‚a‘, ‚1‘, ‚c‘, ‚2‘, ‚e‘, ‚f‘, ‚g‘ };

überraschen mich (mal wieder). Und was ist das für eine Schreibweise in “SELECT UserName as uName, AgE FROM USER”?

Updates wären natürlich sehr schön. Java 5 spielt keine Rolle, und Java 1.4 wird als aktuell bezeichnet, sodass es NestableException einen größeren Raum einnimmt, als es müsste. An anderer Stelle gibt es den Satz “The Discovery component depends on JDK version 1.1.8 or higher”. Also wenn das nicht gegeben ist… Auch Enum könnte man sich natürlich mit Java 5 sparen. Aber das ist eine allgemeine Kritik auch an den Jakarta Commons, da kann der Autor nichts für. Heute könnte man eine Reihe on Verbesserungen vornehmen und auch Alternativen nennen. Im Bereich Date/Time etwa Joda-Time, bei Collections natürlich Google Collections, usw. Die Validator-Klasse macht mittlerweile Java Beans Validation, ein Standard von Java EE 6, quasi überflüssig und Struts Validator spielt heute keine Rolle mehr. Bei den BeanUtils wäre der Hinweise angebracht, dass man mit dynamisch generieten Bytecode schnellere Lösungen realisieren kann als über Reflection. Fürs Datenbank-Pooling gibt es auch Alternativen, sie wären gut im Kapitel 6 aufgelistet. Commons Logging ist auch nicht unproblematisch, eine tiefere Diskussion hätte der Autor bringen können. Und Thread-Pools könnten auch noch erwähnt werden. In Java 7 ersetzt Objects die Commons Klasse ObjectUtils. Zusammenfassung: Fortgeschrittene Entwickler dürften sich das Buch sparen können und kommen mit der API-Dokumentation – die sehr gut und mit vielen Beispielen bebildert ist – sehr weit. Einige der Commons-Bibliotheken sind zudem heute veraltet und spielen in neuesten Projekten keine große Rolle mehr. Die spannenden und aktuellen Themen kommen im Buch leider etwas zu flach weg.

Buchkritik “Google Web Toolkit . GWT Java AJAX Programming. A practical guide to Google Web Toolkit for creating AJAX applications with Java”

Prabhakar Chaganti. Packt Publishing. ISBN 1847191002. 15. Februar 2007. 248 Seiten

Didaktisch ist das Buch deutlich besser aufgebaut als GWT in Action, allerdings geht es deutlich weniger in die Tiefe. Während die Autoren ein einfaches Beispiel zur Internationalisierung angeben und dann schreiben „The I18N support in GWT is quite extensive and can be used to support either simple or complicated internationalization scenarios.“ geht hier das Hanson-Tacy-Gespann deutlicher in die Tiefe. Sehr gut gefallen haben mir den praktischen Beispiele, die Ajax so bekannt gemacht hatten, etwa die Listen mit Kandidaten bei eingegebenen Suchbegriffen oder weiteres. Allerdings gibt es auch ein paar Schwachpunkte. Zunächst betrifft es die GWT-Version: das Buch basiert auf GWT RC1 von Ende 2006. So kommen Neuigkeiten aus GWT 1.4 (aktuell ist GWT 2) nicht zur Sprache. Zudem ist die Formatierung oft ungenügend. Es beginnt schon früh mit dem Satz:

When we wish to draw your attention to a particular part of a code block, the relevant lines or items will be made bold:

calendarPanel.add(calendarGrid);
calendarPanel.add(todayButton);

Und dann steht das noch nicht mal in der Einleitung in bold.

Einrückung und Formatierung sind im ganzen Buch sehr merkwürdig. Die Listings besitzen oft am Anfang eine sehr hohe Einrückung, um dann die verbleibenden Zeilen an den unmöglichsten Stellen umbrechen zu müssen. Einige Fehler sind sicherlich nur Unachtsamkeiten. Wie die folgende:

Primitive types—character, byte, short, integer, long, Boolean, float, and double
Primitive type wrapper classes—character, byte, short, integer, long, Boolean, float, and double

Oder dann zeigt ein Screenshot bei den Primzahlenbeispielen eine Zahl in Anführungszeichen, doch im Quellocode steht:

Window.alert("Yes, "+ primeNumber.getText() ...

Es fehlt hier, genauso wie bei der Fallunterscheidung beim No, das einleitende Hochkomma. Bei Konstruktoren ist ein einfaches super(); sicherlich nicht als explizite Anweisung nötig. Einige Kritikpunkte betreffen die Namensgebung. Da heißt dann eine Methode großgeschrieben ShowText() oder onEventpreview(). Stilistisch lässt sich vielleicht noch for (; rs.next();) mit einem einfachen while( rs.next() ) schreiben. Und warum sehe ich das bei so vielen Autoren Felddeklarationen der Art

private String[] items = new String[]{"apple", "peach", "orange", "banana", "plum", "avocado", ...

Wenn es auch einfach nur

private String[] items = {"apple", "peach", "orange", "banana", "plum", "avocado", ...

heißen könnte? Viele Beispiele tragen im Quellcode für die GWT-Komponenten CSS-Zuweisungen wie
searchText.setStyleName(„liveSearch-TextBox“);
Doch die CSS-Datei ist nicht angegeben! Für die Listings hätte das eigentlich auch wegfallen können—hier muss man die Beispiele von CD oder aus dem Internet nehmen. Mit den Styling ist auch eine andere Sache krumm. Statt <img border=’0′ src=’images/blank.gif’/> für eine Tabelle zu schreiben, wäre hier wohl CSS besser, also etwa <img class="border:0" src='images/blank.gif'/>. Bei den Schaltflächen müssen HTML-Zeichen nicht ausmaskiert werden: new Button("&lt;", this); new Button("&gt;", this); ist schlicht falsch. In der Abbildung auf Seite 41 taucht plötzlich eine Schnittstelle RemoteServiceAsync auf. Die angeblich selbst geschriebene Schnittstelle gibt es nicht, das sollte PrimesServiceAsync heißen. Beim Beispiel mit Auto Form Fill überträgt der GWT-RPC-Service eine HashMap mit den Daten. Eine interessante Alternative wäre, eine serialisierbare Bean zu deklarieren und diese zu versenden. Da kommt in den Beispielen nirgendwo vor. Platz nehmen recht viel Codeduplikate ein, da der Autor bei den Beschreibungen einen Aufbau gewählt hat, in dem erst der Quellcode als Tue-Dies-Anweisungen aufgeführt wird und später die zentralen Stellen beim Was-haben-wir-eigentlich-gemacht-Teil wiederholt. Das kostet natürlich Platz beim Druck und hätte kompakter ausfallen können. Einige Beispiele geben Beispiele für eine Ajax-Bibliotehk an, die sonst aber nicht so weit verbreitet ist. Eine Sache gibt es sogar, die im Action-Buch nicht steht – und die ich auch dort vermisste habe: wie man Dokumente lädt. Hier ist es: HTTPRequest.asyncGet("customers.csv", new ResponseTextHandler() ). Eine Auflistung der unterstützten APIs fehlt jedoch auch hier. In der Summe bleibt ein nettes gut lesbares Buch, welches schnell gelesen ist und auch nicht schwer ist.

Buchkritik “GWT in Action. Easy Ajax with the Google Web Toolkit”

Robert Hanson, Adam Tacy. Manning. ISBN 1-933988-23-1. Juni 2007. 632 Seiten

Die Autoren kennen sich mit GWT gut aus und sind selbst an einigen GWT-Komponenten beteiligt (die allerdings nicht sonderlich spektakulär sind). So hat auch Robert Hanson einen Blog unter http://roberthanson.blogspot.com/ und aktualisiert in hin und wieder mit Neuerungen des GWT. Dieses Detailwissen in GWT scheint dem Autor aber an einigen Stellen im Wege zu sein, wenn etwa das CSS-Styling der Komponenten oder der Aufbau eigener Widgets sowie der native Zugriff auf JavaScript (das sogenannte JSNI) noch vor dem GWT-RPC vorgestellt wird, was dann unter Advanced zählt – da gehört für mich eher JSNI hinein, aber viel weniger GWT-RPC. Da das Buch zu einem der ersten GWT-Büchern gehört, gibt es noch einige Bezüge zu GWT 1.3, die stören aber nicht. Offensichtliche Fehler oder Ungenauigkeiten sind mir bis auf eine fehlende Implementierung bei

public static ServerService getInstance();

und der verrückten StringBuffer-„Optimierung“ nicht aufgefallen.

StringBuffer query = new StringBuffer();

query.append(„param1=“ + URL.encodeComponent(value1));

query.append(„&“);

query.append(„param2=“ + URL.encodeComponent(value2));

query.append(„&“);

query.append(„param3=“ + URL.encodeComponent(value3));

String url = „/search?“ + query.toString();

Und so gibt es bis auf die etwas verwirrenden Kapitelreihenfolgen nichts zu bemängeln.

Kapitel 2 und 10 sind online unter http://www.manning.com/hanson/ als PDF verfügbar. Wollen wir hoffen, dass das Buch bald auf GWT 2 gebracht wird. Ich würde wir auch wünschen, dass es ein Kapitel mit einer Vorstellung von Zusatzkomponenten gib, denn die eingebauten GWT-Komponenten sind genauso gammelig wie die AWT-Komponenten. Smart GWT, bzw. Ext GWT sollten auf jeden Fall genannt und beschrieben werden. In der Summe ein gutes Buch, wenn man sich schon mit einfachen Beispielen aus dem Netz mit dem GWT warmgemacht hat und noch mehr Interna lernen möchte.

Buchkritik: Apache Geronimo, Handbuch für den Java-Applikationsserver

Frank Pientka. dpunkt-Verlag. ISBN 978-3-89864-517-1. 01/2009. 330 Seiten

Der zertifizierte Java EE 5 App-Server Geronimo steht immer ein wenig im Schatten der beiden „Großen“: JBoss und GlassFish. Dass dafür kein Anlass besteht, zeigt sich schnell durch die Möglichkeiten von Geronimo und die Zuneigung von IBM. Wer sich also für Geronimo entschieden hat und ein deutschsprachiges Buch sucht, der wird an Frank Pientkas Buch nicht vorbeikommen, denn es ist neben dem weniger aktuellen „Geronimo schnell + kompakt“ das einzige. Wer die englische Sprache bevorzugt, hat die Auswahl zwischen drei weiteren Büchern. Pientka stellt auf 250 Seiten die zentralen Aspekte von Geronimo vor (plus 50 Seiten Anhang). Für Java EE 5-Einsteiger gibt es ebenfalls ein Kapitel. Zusammenfassend lässt sich sagen: Das Buch behandelt alle relevanten Aspekte und bietet viele Verweise auf weiterführende Webseiten. Das Geronimo-Buch verirrt sich glücklicherweise nicht in Geronimo-Internas wie zum Beispiel „JBoss Administration and Development“ aus dem Jahr 2002 – einem JBoss-Buch, das mit UML-Diagrammen vollgestopft ist Admin-Informationen mit Internas vermischt. Des Weiteren hält sich Pientka an den Java EE 5-Standard. Containerspezifische Java EE-Erweiterungen werden nicht besprochen. Dabei bieten gerade die Apache-Implementierungen weitere Möglichkeiten, etwa JPA-Tuning durch spezielle OpenJPA-Annotationen, JMS-Erweiterungen von ActiveMQ für hierarchische Topics oder verschlüsselte Verbindung beim JNDI-Kontext, also Aspekte, die über den Standard hinausgehen, die Geronimo möglich macht. Wie etwa Hibernate statt OpenJPA als JPA-Provider konfiguriert wird, steht nicht im Buch, vielleicht auch, weil dieses Thema bislang im Internet nur spärlich dokumentiert ist. Die eine oder andere Schwäche findet sich in den Quellcodes. Zeilen wie catch (java.lang.Exception e) und mitunter Zeilenumbrüche, die an den Obfuscated Content erinnern, sind nicht unbedingt schön. Einige Aussagen sind missverständlich, etwa „Geronimo selbst verwendet […] sehr populäre Ajax-Bibliotheken JSON […]“ oder dass Dojo und DWR Teile des Java EE-Standards sind. Wünschen wir uns, dass der Autor das Buch schnell aktualisiert damit es zukünftig Geronimo 2.1 statt Geronimo 2.0, „IIS-Versionen 6 und 7“ statt „auch wenn die aktuellsten IIS-Versionen 5 und 6“, MyFaces statt myFaces, StAX statt STAX heißt und SOAP nicht mehr „Simple Object Access Protocol“ genannt wird. Diese sprachlichen Kleinigkeiten werden sicherlich bereits in der kommenden Auflage zu Java EE 6 behoben sein. Fehler sollten auf http://www.dpunkt.de/buecher/2827.html dokumentiert werden.

Buchkritik: Pragmatic Unit Testing in Java with JUnit

Andy Hunt, Dave Thomas. The Pragmatic Bookshelf. ISBN 0-9745140-1-2. September 2003. 146 Seiten
Kompaktes und nicht allzu tiefes Buch zu Testkonzepten und dem Testframework JUnit 3.x. Gut gefallen haben mir die Vorstellung des CORRECT-Prinzips (Conformance, Ordering, Range, Reference, Existence, Cardinality, Time), die Kurzvorstellung von Mock-Objekten (hier hätte ich mir allerdings etwas mehr Hinweise gewünscht, wobei immerhin Frameworks wie EasyMock zur Sprache kommen) und die Diskussion, wie die Testbarkeit das Systemdesign (positiv) beeinflusst. Die Codequalität ist in Ordnung, aber Anweisungen wie Integer.valueOf(val).intValue() hätte ich gerne als Integer.parseInt(val) gesehen, denn der Aufbau eines Wrapper-Objekts (lassen wir das Caching aus Java 5 außen vor) ist völlig unnötig (aber immerhin ist die Fabrikmethode noch besser als new Integer(val), denn sie kann immerhin auf die gecachten Wrapperobjekte im JDK zurückgreifen ). Die Namenskonvention von Sun hält der Autor bei Variablennamen nicht ein (argument_list, small_list, naughty_url, num_degrees), wobei er auch kein konsistentes Nicht-Einhalten betreibt (ingredientsText oder exitButton). Größtes Dilemma dieser Ausgabe ist aber ihr Alter, da nicht der JUnit 4.x-Zweig verwendet wird ebenso wenig wie Java 5, also keine Generics oder Annotationen. Mit der relativ flachen Beschreibung ist das Buch heute wenig attraktiv.

Buchkritik: Reversing: Secrets of Reverse Engineering

Eldad Eilam. Wiley. ISBN 0-7645-7481-7. 2005. 619 Seiten

Thema des Buches ist die Wiederherstellung von übersetztem Code in ein menschenlesbares Format und gleichzeitig der Schutz von diesem Reverse Engineering Verfahren. Das Buch pendelt zwischen grundlegenden Begrifflichkeiten, wie der Erklärung der Arbeitsweise eines Compilers und wofür die Win 32 API gut ist. Auf der anderen Seite beschäftigt es sich mit IA 32 Assembler-Code. Die Zielgruppe ist daher schwer auszumachen. Sicherlich ist für beide etwas dabei. Wer eher grundlegende Begrifflichkeiten sucht, wird sie hier auf jeden Fall finden und sicherlich nicht den Appendix mit den Prozessor-Flags lesen. Wer in IA 32 Assembler dagegen fit ist, findet viele Anregungen zum Reverse Engineering, Disassemblieren sowie Decompilieren. Zu allen Punkten werden freie und kommerzielle Tools aufgeführt. Der Autor ist nicht ideologisch in Open-Source oder freie Software verliebt und schließt daher kommerzielle Produkte nicht aus; oftmals sind die kostenpflichtigen Lösungen leistungsfähiger. Die Fallbeispiele (Kap. 6, Deciphering File Formats und Kap. 8, Reversing Malware) sind realistisch und ausführlich beschrieben und geben einen guten Eindruck in die Arbeitsweise. Schlussendlich ist auch für .NET-Programmierer etwas dabei, und die Ideen zum Schutz gegen Decompilierung finden auch in der Java-Welt ihre Anwendung.

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.

Buchkritik: Pro Netbeans IDE 6. Rich Client Platform Edition

Adam Myatt. Apress. ISBN 978-1-59059-895-5. Februar 2008, 491 Seiten

Ein aktuelles Buch über NetBeans, welches auf grundlegende aber auch erweiterte Eigenschaften der Entwicklungsumgebung eingeht. Themen sind unter anderem Installation (das 1. Kapitel "Downloading, Installing, and Customizing NetBeans" ist auch online), der Editor, Einstellungen, Projektangaben, Gui-Bilder, Debugging, Profiling, Versionsmanagement, JUnit, Refactoring, Datenbankbrowser, Qualitätsprüfung. Dass das Buch auf der aktuellen Version 6 aufbaut, zeigt sich insbesondere an den letzten Kapiteln, in denen es JRuby und Rails, Web-Services, BPEL, REST, dem Swing-Application Framework und Beans Binding zur Sprache bringt. Dem Autor ist das Kapitel über Swing aber lieber gewesen, denn hier beschreibt er ausführlicher die Technologie, während bei Web-Services nur Einträge in den Dialogen aufgezählt werden, aber nicht erklärt wird, was diese eigentlich sollen. Aber das ist wohl immer der Fall, wenn ein Buch nur zeigen möchte, WIE man mit der IDE etwas macht, aber nicht warum. Für welche Käuferschicht das Buch am Besten geeignet ist, ist schwer zu beantworten. Erfahrene Entwickler, die schon einige IDEs kennengelernt haben (Eclipse, JDeveloper, …) werden mit NetBeans keine Probleme haben. (Aus der Java-Community gibt es vielfach die Meinung, NetBeans ist viel einfacher zu bedienen als Eclipse.) Daher bekommt man mit etwas Rumklicken und aufmerksamem Lesen die meisten Sachen schnell raus, zumal die Webseite von Sun voll von Tutorials insbesondere für die fortgeschrittenen Themen ist. Wer ein Gespür für Entwicklungswerkzeuge hat, und gerne Online-Tutorials liest, wird mit http://www.netbeans.org/kb/ auch glücklich. Zumal bei Sun Artikel zur Java ME-Entwicklung, C(++) oder UML-Modellierung stehen, die das Buch überhaupt nicht ankratzt. Schade eigentlich, denn vermutlich dürfte UML für die meisten Leser interessanter sein als einen BPEL-Web-Service auf Glassfish zu deployen. Das letzte Kapitel „Developing Rich Client Applications“ hat aber nichts mit der Entwicklungsumgebung selbst zu tun, sondern stellt kurz das NetBeans RCP vor. Hier ist die Zielgruppe eine völlig andere. Denn der Bediener einer IDE ist nicht unbedingt einer, der mit dem RCP Desktop-Anwendungen schreibt. Sehr fragwürdig ist daher auch der Titel „ Rich Client Platform Edition“; hier ist man verleitet anzunehmen, dass es ein Buch über das RCP-Framework ist. Doch nein, es ist nur ein Buch über die Bedienung einer Entwicklungsumgebung.

Buchkritik: Java EE 5 Development using GlassFish Application Server

David Heffelfinger. Packt Publishing. ISBN 1847192602. Oktober 2007. 408 Seiten

Trägt ein Buchtitel eine Technologie und gleichzeitig ein Produkt im Namen, ist das eine schwere Mischung. Entweder wird auf die Administration des Servers eingegangen, oder wir finden ein Lehrbuch, das nur Beispiele lauffähig auf einem speziellem Produkt vorweisen kann. Heffelfingers Werk gehört in keine Kategorie. Der Bezug zu Glassfish ist minimal, und wer mehr sucht als eine kleine Installationsanweisung – die es auch im Netz bei Sun gibt –, wird enttäuscht. Da die sauberen Java EE Beispiele den Entwickler nicht an einen speziellen Container binden, sind seine Quellcodes auch auf JBoss oder Geronimo ablauffähig. Wer nun Java EE lernen möchte, ist sicherlich darin interessiert, seine Beispiele zumindest auf einem Server laufen zu sehen. Aus Sicht der Zielgruppe eines Buches wohl eher unnötig einschränkend.

Didaktisch und fachlich gibt es das ein oder andere zu bemängeln. Einige Quellcode-Snippets bekommen ihr @Override vor den überschriebenen Servlet-Methoden, andere nicht. Und warum wird der String-Konstruktor laienhaft verwendet?

application.setAttribute("applicationAttribute", new String( "This string is accessible accross sessions."));

Oder parameterName aus String deklariert, aber später dennoch einmal explizit gecastet?

String parameterName = (String) initParameterNames.nextElement();
out.print(config.getInitParameter((String) parameterName));

Oder ein StringBuffer statt der guten allen String-Konkatenation eingesetzt?

@Override public String toString() {
StringBuffer fullNameBuffer = new StringBuffer();
fullNameBuffer.append(firstName);
fullNameBuffer.append(" ");
fullNameBuffer.append(lastName);
return fullNameBuffer.toString();
}

Hier ist ein return firstName + " " + lastName; doch wirklich angenehmer zu lesen und auch die Performance gar nicht schlechter.

Ebenso heiße ich es nicht für sinnvoll, auf das MVC-Konzept auch bei JSP/Servlets zu verzichten. Didaktisch dürften JSPs eher vor Servlets Sinn ergeben. JSPs gehen mir auch zu früh runter auf implizite Objekte und eine Skriptlet-Ebene ohne früh schon EL und die Standard-TagLib zu erklären. Die web.xml-Datei bekommt auch immer unterschiedliche Schema-Dateien und Versionen untergeschoben: Einmal 2.4, dann wieder das aktuelle 2.5. Beim Fehlerhandling findet sich:

StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
exception.printStackTrace(printWriter);
out.write(stringWriter.toString());

Warum der Autor nicht einfach exception.printStackTrace(new PrintWriter(out)); schreibt, ist mir ein Rätsel. (out ist ein JspWriter extends Writer und printStackTrace() möchte einen PrintStream oder PrintWriter.) Dann ist die Definition einer Bean falsch: „All of its variables must be private.” Die von Properties verwendeten Attribute sind in der Regel private, aber sie müssen es nicht sein. Auch sind natürlich public static final-Konstanten erlaubt. (Wunderbar, dass ausgerechnet im zugehörigen Beispiel die Variablen nicht private sind, sondern paketsichtbar.)

Die Datenbank ist mit zehn Tabellen vielleicht für Einstiegerbeispiele doch etwas zu kompliziert. Als Leser ist man erschrocken, plötzlich ein Servlet zu sehen, welches an die Datenbank geht und SQL-Anweisungen ausführt. Warum sieht man so einen Wahnsinn noch im Jahre 2008? Die Datenbank-Connection wird zudem nicht korrekt im finally-Block geschlossen. Es reicht, auf Seite 120 gebe ich auf und wage den Wiedereinstieg auf Seite 347. (Übersprungen werden Standard TagLibs, JSF, JMS, Security, EJB, Web-Services.) Zum Abschluss ein kleiner Höhepunkt: Heffelfinger geht praktisch auf Facelets ein und zeigt auch ein Beispiel für das Templating, ein Weiteres für Ajax4jsf und JBoss Seam findet sich ebenso. Ein erneuter Lichtblick: Der Autor verwendet vorbildlich die vorgesehene Dateieindung .jspf für inkludierte JSP-Fragmente. Dann noch etwas IDE-Integration (NetBeans und Eclipse) und der Spuk ist vorbei.

Buchkritik: Java/J2EE Job Interview Companion – 400+ Questions & Answers

Arulkumaran Kumaraswamipillai, Sivayini Arulkumaran. Lulu.com. ISBN 1411668243. April 2007. 355 Seiten

Es handelt sich um ein interessantes Buch, welches ich in dieser Form noch nicht gelesen habe. Meist dreht es sich ja um Anwendungsdesign oder harte Technologien, aber ein Buch, welches für Java-Entwickler mögliche Bewerbungsfragen sammelt, ist mir neu. Daher sollte das Werk auch von zwei Seiten beleuchtet werden: Vom Interviewer und vom Interviewten. Beide Gruppen erhalten mögliche Standardfragen zu diversen Themen aus Java SE, Java EE (+Hibernate +Spring) sowie Anwendungsdesign. Das Niveau wechselt zwischen „Was ist der Unterschied zwischen String und StringBuffer?“ und „Erkläre Inner Join und Outer Join.“ Beide Parteien erhalten ausreichende Antworten, wobei das Buch nur kurze Erklärungen liefert und auf breite Ausschweifungen verzichtet; sonst könnte leicht ein 2000 Seiten starker Wälzer daraus werden. Die Fragen sind gut gemischt und decken optimal das Standardwissen jedes Entwicklers ab. Trotz des Lobes kann die Erwähnung einiger Fehler nicht unterbleiben. Ein Beispiel zum Thema Varags: „The type must be Object and it must be the last argument or the only argument to the method.” Natürlich kann jeder Typ bei Varags verwendet werden, int… genauso wie String…. Hinzu kommen noch ein paar Kleinigkeiten, wie \n statt %n in printf(), klein geschriebene Enum-Konstanten, String-Konkatenationen im SQL-Statement für variable Teile statt Prepared-Statement und nicht erreichbarer Programmcode beim Schließen von JDBC-Connections, wenn es vorher eine Exception gab. Dennoch alles in allem ein gutes Buch zur Vorbereitung und auch zum Auffrischen des Java-Wissens für Entwickler, die schon ein paar Jahre Java programmieren.

Buchkritik: Agile Java Development with Spring, Hibernate and Eclipse

Anil Hemrajani. Sams. ISBN 0-672-32896-8. Mai 2006. 360 Seiten

Lehrbücher, die anhand eines Beispiels versuchen, die agile testgetriebene Softwareentwicklung mit Ant, Hibernate, HSQLDB und Spring (Web mit Spring MVC) zu zeigen, gibt es meines Wissens keins – bis auf dieses. Vielleicht ist das auch kein Wunder, denn schon die Themen Spring/Hibernate füllen dicke Bücher. Hemrajanis Buch will aber gar nicht in die Tiefe gehen, sondern zeigt, wie mit Open-Source Tools ein Online Timesheet System aufgebaut wird. Der Autor streift dabei weitere Technologien, wie die Eclipse IDE, Logging, Profiling, und stellt Links zu vielen Tools übersichtlich am Ende jedes Kapitels vor. Die Zielgruppe für das Buch dürften Personen sein, die bisher mit dem Standard Java gearbeitet haben, und nun lernen wollen, mit welchen Enterprise Technologien sich Web-Anwendungen bauen lassen. Wer eine detaillierte Beschreibung in JUnit, Hibernate und Spring sucht, ist mit dem Buch sicherlich nicht gut beraten. Schade ist auch, dass Hibernate über die HBM.XML-Dateien konfiguriert wird und nicht die Sprachmöglichkeiten über Java 5 (Annotationen) und der JPA-Entity-Manager zum Einsatz kommen. Dass nicht Spring 2 den Kern bildet, ist zu verschmerzen, und das statt Spring MVC nicht Spring WebFlow zum Einsatz kommt ist wohl eher eine Frage des didaktischen Wegs und dem Zeitpunkts des Drucks zu verschulden.

Buchkritik: Beautiful Code: Leading Programmers Explain How They Think

Beautiful Code: Leading Programmers Explain How They Think
Andy Oram, Greg Wilson. O’Reilly. 2007. 618 Seiten
Bekannten Autoren und Software-Architekten geben in 33 Kapiteln viele Beispiele ihrer Kunst, und Einblicke in ihr Schaffen. Doch sehr spezielle Beispiele in diversen Programmiersprachen machen es für Java-Programmierer schwer, hier „schönen Code“ zu entdecken. Unter dem Strich bleibt nicht viel für Java-Entwickler über, wenn Programmiersprachen wie C, Ruby, LISP ihren Platz finden und Algorithmen vorgestellt werden, die für die allermeisten kaum relevant sind. Interessant ist es allemal, und wer sich viel Zeit für die Einarbeitung nimmt, wird auch sicherlich viel entdecken, zumal das Design einen größeren Stellenwert einnimmt, als der Quellcode an sich. Bei den wenigen Java-Programmen gibt leider etwas zu bemängeln. Einmal ein einfacher Fehler auf Seite Seite 478, in dem die Klammerung falsch ist:

class Sample {}
public static void main(String[] argv) {
System.out.println("Hello World");
}

Der zweite Hammer haut aber stärker rein und ist definitiv kein Beispiel für „Beautiful Code“. Seite 332 stellt eine EJB Session-Bean FileReaderBean vor, die über eine FileInputStream Daten vom Dateisystem holt – das ist nun wirklich nicht in Ordnung. Toll finde ich, dass die Erlöse an Amnesty International gehen: „All royalties from this book will be donated to Amnesty International.”. Das nette Kapitel Code in Motion ist online verfügbar.

Buchkritik: Das Java Codebook

Marcus Wiederstein, Marco Skulschus, Mark Donnermeyer, Dirk Brodersen, Benjamin Rusch. Addison-Wesley. ISBN 3-8273-2059-3. 2003. 858 Seiten
Programmabschnitte, sog. Snippets, gibt es im Internet genug (wir wäre es alternativ mit dem Java-Almanac?) und wer eine Suchmaschine bedienen kann, wird immer, ja immer, die Bibliothek oder den Quellcode-Schnippsel finden, die er sucht. Um so erstaunlicher finde ich es, wenn Verlage Quellcode-Kochbücher veröffentlichen, ob sie nun Codebook oder Cookbook heißen. Ernsthaft: Wer eine Klasse zur Bruchrechnung sucht oder ein Beispielprogramm zum Aufbau eines Swing-Fensters, geht sicherlich nicht zum Regal, sucht im Index nach „Bruch“ und holt sich dann die Klasse von der CD. Daher die Frage – ist ein Buch wie „Das Java Codebook“ notwendig? Das Positive zuerst: Die Kapitel über reguläre Ausdrücke und Applets (Daten im Cookie speichern, Uploads, Applet-Konverter für Tags), die kleinen Beispielprogramme, in denen man etwa über ein BufferedImageOp.filter Bilder heller/dunkler macht, sowie Hinweise zur Transparenz und der Index finde ich prima. Eigentlich sind Bücher mit Quellcode gut, denn Software-Entwickler lesen im Allgemeinen zu wenig. Das Studium von Quellcode hilft jedem Entwickler, neue Idiome zu lernen und seine Fähigkeiten zu verbessern. Je nach Schwerpunkt des Buches lernt man weitere Möglichkeiten der Standardbibliothek kennen oder neue Open-Source-Bibliotheken. Soweit die Möglichkeiten guter Codebooks. Leider hat das Java Codebook dann doch die eine oder andere Schwachstelle, so dass man Software-Entwicklern vielleicht doch besser direkt zur Google-Suche raten sollte. (Immerhin gibt es das Buch als PDF.) Die Probleme im Detail: Die Klasse

public class CalcExample {
static final BigDecimal ZERO = new BigDecimal(0);
static final BigDecimal ONE = new BigDecimal(1);
static final BigDecimal FOUR = new BigDecimal(4);

deklariert drei Variablen (Sichtbarkeit könnte auch anders sein), doch vergisst, dass es ZERO, ONE, TEN schon in BigDecimal gibt. In anderen Beispielen gefällt mir die Schreibweise der Felder nicht. Einiges ist nach der Bauart String []array, also Typ, Leerzeichen, Variablenname aufgebaut. Das habe ich nach 11 Jahren Java hier zum ersten Mal gelesen. Zumal sich die Autoren hier uneins zu sein scheinen, denn sie verwenden auch String[]. Die fünf Autoren des Buchs folgen demnach keiner einheitlichen Coding-Konvention. Ein weiteres Thema betrifft die Methodennamen: Überwiegend werden englische Bezeichner (setNumber, less100, …) gebraucht, doch lassen sich innerhalb eines Beispiels Vermischungen mit deutschen Variablennamen entdecken, wie das Feld ZEHN. Einige Autoren mögen (immer noch) die Klassen Hashtable und Vector, andere nutzen doch besser List und Map – hat denn keiner der Autoren die anderen Kapitel gelesen und kommentiert? Bei den Datenstrukturen frage ich mich wirklich, was denn arrayList.add(new String(new java.util.Date().toString())); für eine Anweisung sein soll. Und warum wird ein Stack noch mal neu implementiert? OK, der Original-Stack erbt von Vector, was vom Design total verpfuscht wurde, aber dann könnte man doch immer noch den neuen Stack so implementieren, das er an den alten Stack delegiert, anstatt alle Operationen komplett mit einer ArrayList neu zu implementieren. (Und dann noch die fragwürdige Methode search() zu übernehmen.) Eine weitere Schwachstelle, die ich in der Insel weitestgehend versuche zu vermieden, sind Windows-spezifische Pfadangaben, wie etwa bei new FileOutputStream(„c:\\buecher.ser“). Bei IO-Beispielen fehlt oft das close() im finally. Vor allem bei HTTP-Servern ist das kritisch. Im JSP-Kapitel findet sich plötzlich ein JDBC-Close im finally; also hat es nicht jeder der Autoren vergessen. Frage: Was gibt dieses Programm bei Argumenten auf der Kommandozeile aus?

package javacodebook.io.stdout;
public class StdOut {
public static void main(String[] args) {
String text = "Hallo Welt";
//Wenn Text angegeben, dann diesen ausgeben
if(args.length < 1)
for(int i = 0; i < args.length; i++)
System.out.println(args[i]);
else
System.out.println(text);
}
}

Dass ist wohl eher eine Zertifizierungsfrage statt eines sinnvollen Codebeispiels, denn ist die Anzahl der Argumente kleiner 1, gibt es keine Argumente und die Schleife ist nutzlos. Genauso falsch ist der Satz „JDBC benutzt dabei die Interfaces Connection, Driver und DriverManager.“ Schade, denn DriverManager ist eine Klasse. Sollte es auch, denn aus dieser Zentrale erhält man durch die statische Methode getConnection() eine Verbindung. Im Anhang finden sich dann noch ein paar Dreher in der Groß-/Kleinschreibung. Z. B. beginnen einige Bezeichner in der Tabelle „Java Native Interface Typen“ mit Großbuchstaben. Besser wären „int“ statt „Int“ sowie „void“ statt „Void“ usw. Ähnliches gilt für JscrollPane, was zu JScrollPane werden sollte. Unter „Relationale Operatoren“ findet sich folgender Satz bei ==-Operator: „a == b ergibt true, wenn a gleich b ist. Handelt es sich bei a und b um Referenztypen, so ist der Rückgabewert dann true, wenn beide auf dasselbe Objekt zeigen.“ Wir sollten den Sonderfall a = b = NaN aber nicht Außeracht lassen, denn gerade dann ist a = b, aber das Ergebnis nicht true. In der Tabelle „Klassenobjekte für den primitiven Datentyp“ sollte Void besser nicht auftauchen, da es sich nicht um einen primitiven Datentyp handelt. Oder Void stehen lassen, aber die Überschrift anpassen. Einige Kritikpunkte betreffen die Auswahl der Klassen. Die Klasse Fraction sollte vielleicht besser einer bekannten Open-Source-Bibliothek entstammen und die Matrizen sowie der umfangreiche Quellcode nicht unbedingt abgebildet werden. Für CSV-Dateien wären populäre Standard-Klassen sinnvoller. Der Tipp 186 für Timer sollte diesen nicht selbst implementieren, sondern die zwei (!) Timer-Klassen der Java-Lib vorstellen. Da ein Codebook grundsätzlich eine unendliche Sache ist, könnten weitere Snippets eingebracht werden. Bei den Zufallszahlen wäre z. B. SecureRandom gut untergebracht. Das Beispiel FindInFile, was händisch nach einem String in einer Datei sucht, lässt sich viel effektiver mit NIO (mit Standard-Beispiel von Sun) lösen. Das NIO-Kapitel kommt mit nur zwei Beispielen daher (Datei kopieren und File-Lock). Das ist eine magere Ausbeute. Später kommt noch ein NIO-Server dazu. Der Verweis auf eine einfache NIO-Bibliothek (wie xSocket) wäre dann wünschenswert. Um ein Fenster mittig zu positionieren, muss man nicht rechnen, hier reicht eine Java-Funktion. Wenn es sich schon um ein Java 1.4 Buch handelt, dann sollte ImageIO Grafiken laden. Die Swing-Beispiele sind relativ unspektakulär. Hier wäre es wohl sinnvoller statt „wie erzeuge ich einen Button“ oder „wie etwas mehr mit den Modellen zu machen“, einen Dateibaum in ein JTree zu setzen. Und stilistisch wertvoll ist der Hinweis mit der JDBC-Verbindung in einem JSP-Tag sicher nicht. Und wo sind die DAOs? Bei JMS stimmt es zwar grundsätzlich, dass in einer Tabelle bei Programmiersprachenunabhängigkeit „Nein“ steht und bei HTTP „Ja“, doch allgemeingültig ist das nicht. Für ActiveMQ gibt es ein standardisiertes Protokollformat (OpenWire) und APIs für diverse andere Programmiersprachen. Das gleiche gilt auch für IBMs WebSphere MQ (früher MQSeries) – sicherlich eines der besten MOMs -, das heterogene Plattformen verbindet. Einen XML-Parser über die Anweisung org.apache.xerces.parsers.DOMParser parser = new org.apache.xerces.parsers.DOMParser(); statt über JAXP zu erfragen ist nicht schön sondern fast grob fahrlässig. Zudem haben auch die JAXP-Parser Features, obwohl die String-Kennungen dann immer ein wenig anders aussehen. Zu Tipp 196: Wann immer man sich mit getGraphics() einen Grafik-Kontext holt, sollte man ihn auch wieder freigeben. Dieser Hinweis fehlt leider in den Beispielen. Farbkonstanten sollten groß geschrieben sein, also Color.WHITE, statt Color.white, zumindest seitdem Sun diese Konvention in Java 1.4 eingeführt hat.

Erst wenn der letzte Programmierer eingesperrt und die letzte Idee patentiert ist, werdet ihr merken, dass Anwälte nicht programmieren können.