tutego

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension

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.

Labels: Rezension, Spring

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.

Labels: Rezension

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.

Labels: Rezension

Ein frühes Buch (Juni 2006) zu Java 6, aber es zeigt alle wesentlichen Eigenschaften der neuen Version. Sehr gut gefallen hat mit die Beschreibung von CookieHandler, CookieManager & Co. KG, etwas, was ich noch nie ordentlich erklärt gefunden habe. Der einzige Fehler, der mir aufgefallen ist, befindet sich auf Seite 111, wo eine Variable statt rs (für ResultSet) fälschlicherweise st heißt. Eine präzisere Beschreibung für Web Services und JAXB liefert das Buch leider nicht -- nur ein paar Standard-Beispiele und eine schlaffe Aufzählung der Annotationen -- aber dafür gibt es ja andere Bücher aus der Ecke der Java EE Literatur. Auch StAX ist nicht sonderlich präzise und späteren Neuerungen, wie Java DB oder GroupLayout finden keine Erwähnung. Das gleiche gilt für neue Funktionen copySign(), getExponent(), nextAfter(), nextUp(), scalb() aus Math/StrictMath. Eigentlich wäre jetzt Zeit für ein Buch-Update.

John Zukowski. APress. ISBN 1590596609. 220 Seiten

Labels: Rezension