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.