Open-Source Java-Bücher Hits und Tops

XDo­clet in Action
Craig Walls, Nor­man Richards. Man­ning. ISBN 1−932394−05−2. 2004. 600 Sei­ten
XDo­clet selbst stammt von Rickard Öberg, der auch das Vor­wort für das Buch geschrie­ben hat, aber Craig (war selbst XDo­clet Com­mit­ter) und Nor­man leis­ten gute Arbeit, XDo­clet voll­stän­dig zu beschrei­ben – Öberg hat Kor­rek­tur gele­sen. Der Ursprung des Buches liegt laut Auto­ren in der Moti­va­ti­on XDo­clet selbst bes­ser zu ver­ste­hen, doch die Auto­ren sind all­ge­mein und gründ­lich genug, damit Leser unter­schied­li­cher Bil­dungs­schich­ten etwas davon haben. (Aller­dings hört es in der Tie­fe dann irgend­wann ein­mal auf, das hat aber nichts mit XDo­clet selbst zu tun, son­dern etwa rund um EJB-Asso­zia­tio­nen.) Das ers­te Kapi­tel führt die Grund­la­gen von Code­ge­ne­rie­rung ein und wie XDo­clet ins Bild passt. Akti­ver wird von pas­si­ver Code­ge­ne­rie­rung unter­schie­den, unter­schied­li­che Ursprungs­for­men wer­den geschrie­ben und dis­ku­tiert ob und wie XDo­clet ins eige­ne Pro­jekt passt. Kapi­tel 2 ist tech­ni­scher und führt Tags und Ant-Tasks ein, um Gene­rie­rung von Todo-Lis­ten zu zei­gen. XDo­clet Tasks und Sub­tasks wer­den kurz vor­ge­stellt. Es folgt eine Kurz­ein­füh­rung in Tem­pla­tes für die Code­ge­ne­rie­rung, etwas detail­liert viel­leicht zu Anfang, aber in Ord­nung. Im spä­te­ren Kapi­tel kommt das noch sehr genau zur Spra­che. Es folgt das Kon­zept der wich­ti­gen Mer­ge-Points und das Kapi­tel schließt mit dem Big­ger-Pic­tu­re und der Fest­stel­lung, dass Meta­da­ten nur an einer Stel­le ste­hen soll­te und Red­un­dan­zen mini­miert wer­den müs­sen. Es folgt der zwei­te Abschnitt, der sich kon­kret mit dem EJB-Doclet, und XDo­clet fürs Web beschäf­tigt. Kapi­tel 3 ist für die klas­si­schen J2EE 1.4 Ent­wick­ler das wich­tigs­te Kapi­tel. Das Bei­spiel ist mit einem Web­log gut und anschau­lich gewählt. Dass die Pro­per­ty im UML-Dia­gramm aller­dings „test“ heißt ist ein Feh­ler; es soll­te „text“ hei­ßen. Alle zen­tra­len Tags wer­den an Bei­spie­len gezeigt, also wie ein Ses­si­on-Bean getagt wird, eine Ent­i­ty-Bean und die Bezie­hun­gen der Ent­iy Bean auf­ge­baut, und wie eine Fas­sa­de und Uti­li­ty-Klas­se gene­riert wer­den und was im Prin­zip dar­in steckt (Quell­code wäre gut gewe­sen hier). Es folgt die Gene­rie­rung eines Value Objects (VO) was die Auto­ren hier mit dem Data Trans­fer Object (DTO) gleich­set­zen, aber heut­zu­ta­ge trennt man die Kon­zep­te. Matcher für unter­schied­li­che VOs kom­men zur Spra­che genau­so wie Aggre­ga­tio­nen und Com­po­si­tes, also das auch die asso­zi­ier­ten Objek­te einer CMP mit in das VO auf­ge­nom­men wer­den. Die Beschrei­bung könn­te aller­dings etwas detail­lier­ter sein und es wäre eine Berei­che­rung, wenn die Auto­ren alle Sze­na­ri­en, also 1:1, 1:n, n:m einem Bi- und ein­mal Uni­di­rek­tio­nal durch­ge­spielt hät­ten. Das Kapi­tel schließt mit den Sicher­heits-Tags, Finder/Selector und einer Über­sicht, wel­che Datei­en XDo­clet für das Blog-Bei­spiel gene­riert, Trans­ak­ti­ons­at­tri­bu­ten, DAOs für BMP und Messa­ge Dri­ven Beans. Gewünscht hät­te ich mir noch eine Zusam­men­fas­sung mit einer Gegen­über­stel­lung der Tags mit dem Ergeb­nis im Deploy­ment-Deskrip­tor bzw. Quell­code. Kapi­tel 4 wid­met sich der Web-Tier. Der Ant-Task webdoclet wird vor­ge­stellt und es beginnt mit dem Tag für Ser­v­lets, Fil­ter, Lis­tener und JSP-Tag-Libs, damit die web.xml erstellt wird. Das Bei­spiel führt die Idee des Blogs fort. Die Qua­li­tät der Quell­code­bei­spiel ist rela­tiv gut wobei mir bei Lis­ting 4.7 auf­fällt, dass die Auto­ren fol­gen­des für doEndTag() schrei­ben:

try {
 if(date != null) {
  SimpleDateFormat formatter = new SimpleDateFormat(format);
  pageContext.getOut().write(formatter.format(date));
 }
} catch (IOException e) { }
return EVAL_PAGE;

Die IOException zu schlu­cken ist viel­leicht nicht so toll (in den übri­gen Bei­spie­len wird schön geloggt) und ich fra­ge mich, war­um der String format zwar in der Objekt­va­ria­blen gehal­ten wird, aber war­um nicht gleich SimpleDateFormat (und dann auch vom Basis­typ DateFormat, der für format() reicht). Mög­li­cher­wei­se wis­sen die Auto­ren, dass die java.util.Format-Klas­sen nicht Thread-sicher sind, ver­ges­sen aber, dass die Tag-Objek­te nicht wie die Ser­v­let-Klas­sen geteilt wer­den, son­dern der Ser­v­let-Con­tai­ner wegen des Zustands der Tag-Objek­te immer neue auf­baut (sogar bei jedem Request!) und es somit kei­ne par­al­le­len Zugrif­fe auf doEndTag() gibt. Es folgt das 5. Kapi­tel, wel­ches die XDo­clet-Unter­stüt­zung für Struts und Web-Works vor­stellt. Es wer­den zwei wich­ti­ge Mer­ge-Points für web.xml vor­ge­stellt, dann fol­gend Details über die Struts-Actions und Vali­da­to­ren und Web­Work, bei dem sich die Aus­sa­ge „Ano­t­her web-lay­er frame­work that is gai­ning in popu­la­ri­ty is OpenSymphony’s Web­Work“ nicht bewahr­hei­tet hat. Kapi­tel 6 springt dann wie­der in die Welt der App­li­ca­ti­on-Ser­ver und beschreibt Tags für die Con­tai­ner-spe­zi­fi­schen Deploy­ment-Deskrip­to­ren exem­pla­risch an JBoss und Web­Lo­gic. Das been­det den zwei­ten Abschnitt und der drit­te Abschnitt beginnt mit spe­zi­el­le­ren Tech­no­lo­gi­en Hibernate/JDO/Castor, der alten Axis-Ver­si­on, JMX, Mock-Objek­te und Port­lets. Hiber­na­te wird nicht all­zu tief vor­ge­stellt, was ein ech­tes Man­ko ist, denn die XDo­clet-Unter­stüt­zung ist/war per­fekt und Ent­wick­ler grif­fen ger­ne zu XDo­clet, um sich die .hbm.xml gene­rie­ren zu las­sen. Hier muss dann die Doku­men­ta­ti­on aus dem Anhang oder der Web­sei­te aus­hel­fen, denn das Buch kommt über ein paar ein­fa­che Pro­per­ties und Rela­tio­nen nicht hin­aus, denn sofort geht es zu JDO und dann Cas­tor JDO, Cas­tor XML. Es fol­gen Web-Ser­vices mit Apa­che SOAP (dem Vor­gän­ger von Axis 1) und Axis 1 dann in Kapi­tel 8 und wie XDo­clet die Deploy­ment-Deskrip­to­ren gene­riert. Es folgt der Hin­weis, das für die Seria­li­zer und Dese­ria­li­zer kei­ne Tags exis­tie­ren, statt­des­sen ein Mer­ge-Point genutzt wer­den muss. Damit schließt das Kapi­tel und das Kapi­tel 9 wid­met sich einer Kurz­ein­füh­rung zu JMX und kommt dann zu Gene­rie­rung von MLET-Datei­en und der unter­schied­li­chen Descrip­to­ren für Con­tai­ner wie JBoss oder MX4J. Kapi­tel 10 ent­fernt sich kom­plett von Java EE-Tech­no­lo­gi­en und geht auf Mock-Objek­te ein; eine Schnitt­stel­le Auto­mo­bi­le wird getaggt und XDo­clet erzeugt eine Klas­se Auto­mo­bi­le­Mock. War­um die Auto­ren aller­dings eine Schnitt­stel­le mit 15 (!) Ope­ra­tio­nen dekla­rie­ren und nicht 1 und dann auch nicht bei Ihrem Blog-Bei­spiel blei­ben bleibt im Dun­keln. Die 15 Ope­ra­tio­nen füh­ren jedoch dazu, dass die AutomobileMock.java über 700 Zei­len dick ist und nicht abge­bil­det wer­den kann. Anschlie­ßend zeigt ein Bei­spiel wie im JUnit-Test­fall das Mock-Objekt initia­li­siert und genutzt wird. Da XDo­clet kein bekann­tes Mock-Frame­work nutzt, ist die Bedeu­tung der Lösung gering. Kapi­tel 11 wür­de eigent­lich viel bes­ser an die Java EE Tech­no­lo­gie pas­sen, denn es beschreibt Port­les und wel­che XDo­clet-Tags es für wel­che Ein­trä­ge im Deploy­ment-Deskrip­tor portlets.xml gibt. Der letz­te Abschnitt, begin­nend mit Kapi­tel 12, geht tie­fer in die Archi­tek­tur von XDo­clet ein und beschreibt, wie das Tem­pla­ting funk­tio­niert und eige­ne Tags und Tasks ent­wi­ckelt wer­den. Der 4. Abschnitt nimmt viel Raum ein. Zunächst stell­te Kapi­tel 12 her­aus, war­um man sich mit Code­ge­ne­rie­rung beschäf­tig­ten soll­te. Es beginnt mit der Aggre­ga­ti­on, also dem Sam­meln von Infor­ma­tio­nen und einem ein­fa­chen Tem­pla­te; dabei wer­den die Grund­ele­men­te vom .xdt-For­mat der XDo­clet-Tem­pla­te-Datei­en vor­ge­stellt. Es folgt die Trans­for­ma­ti­on mit einem Fac­to­ry-Gene­ra­tor – das ist anschau­lich und für jeden gut ver­ständ­lich. Danach spie­len die Auto­ren den Tem­pla­te-Mecha­nis­mus für einen Com­mand-Kon­fi­gu­ra­ti­on wei­ter und stel­len Tags vor um alle Attri­bu­te aus den Java-Klas­sen, etwa Fel­der, Kon­struk­to­ren aus­zu­le­sen; das gan­ze erin­nert ein wenig an Reflec­tion. Es folgt ein eige­ner Con­tent-Tag-Hand­ler und Body-Tags, denn nicht alle lässt sich in XDo­clet so ein­fach umset­zen; es ist wie die JSTL unter Ver­bot von Skript­lets: Nur lesen ist ein­fach, aber Zwi­schen­zu­stän­de hal­ten wird schnell unle­ser­lich. Das Kapi­tel schließt mit einem Abschnitt, danit eige­ne Tags wie ein­ge­bau­te aus­se­hen – Ant steht natur­ge­mäß im Mit­tel­punkt. Im Kapi­tel 13 fol­gen­den XDo­clet-Erwei­te­run­gen und Tools, wor­un­ter die Auto­ren die IDE-Inte­gra­ti­on in Intel­liJ und Eclip­se (mit JBoss IDE) mei­nen und das MDA-Werk­zeug AndroM­DA und Midd­le­gen, was Daten­ban­ken aus­liest und aus dem Sche­ma XDo­clet-ver­se­he­ne EJB-CMP-Klas­sen (oder JDO-Klas­sen) gene­riert. Abschlie­ßend gibt der Anhang A eine aus­führ­li­che Instal­la­ti­ons­an­lei­tung für Ant und XDo­clet und Anhang B lis­tet die Tasks/Subtasks auf, Anhang C gibt auf über 100 Sei­ten eine schö­ne Über­sicht über alle XDo­clet-Tags, Anhang D die XDt-Tem­pla­te-Syn­tax und zu aller letzt phi­lo­so­phiert Anhang E über die Zukunfts­aus­sich­ten von XDo­clet. So kommt zu Spra­che, dass es XDo­clet 2 mit einer neu­en Code-Gene­rie­rungs-Engi­ne Genera­me gibt sowie einem Code-Tem­pla­ting der auf Jel­ly bzw. Velo­ci­ty zurück­greift. Dass XDo­clet durch Anno­ta­tio­nen kom­plett ster­ben wird konn­ten die Auto­ren 2004 nicht ahnen; nur ein Jahr Mit­te 2005 spä­ter bleibt die Uhr bei Ver­si­on 1.2 ste­hen. Was ist also mei­ne Zusam­men­fas­sung für das Buch? Wer mit XDo­clet noch in alten Pro­jek­ten zu tun hat, der wird die­ses Buch mögen. Es ist aus­führ­lich und gut und die Bei­spie­le sind her­vor­ra­gend, fast immer durch­ge­hend und zu abge­ho­ben. Der Quell­code im Buch ist mehr­heit­lich in Ord­nung, es gib immer wie­der Klei­nig­kei­ten, die mich an den All­ge­mei­nen Java-API Kennt­nis­sen und Wis­sen um die gesetz­ten Java-Idio­men der Auto­ren zwei­feln las­sen. Bei:

String logLevel = config.getInitParameter( "LogLevel" );
if ( logLevel.equals("debug") )

muss man sich fra­gen, ob man wirk­lich auf einen poten­zi­el­len null-Kan­di­da­ten equals() auf­ru­fen möch­te – die Vari­an­te "debug".equals(logLevel) ist da eigent­lich ange­brach­ter. Im Lis­ting 7.9 ist eine public Stan­dard­kon­struk­tor als ein­zi­ger Kon­struk­tor ohne Java­Doc auf­ge­führt; die paar Zei­len hät­te sich die Auto­ren auch schen­ken kön­nen und im glei­chen Bei­spiel sind die Para­me­ter­va­ria­blen nicht pri­ckelnd:

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

Das glei­che auch für Pro­per­ty name und owner. Vom Bei­spiel 8.1 bin ich ent­täuscht. Die String-Varia­ble VOWELS ist mit "AEIOUaeiou" vor­be­legt und dann folgt in der Metho­de:

Character c = new Character( word.charAt(i) );
if ( VOWELS.indexOf(c+"") >= 0 )
…
endBuffer.append( c.charValue() );

Hier Character-Objek­te auf­zu­bau­en ist gro­ber Unfug, ein

char c = word.charAt( i );
if ( VOWELS.indexOf(c) >= 0 )
…
endBuffer.append( c );

hät­te es voll getan (die String#contains(CharSequence)-Metho­de gab es damals noch nicht, sie wur­de erst mit Java 5 ein­ge­führt). In Lis­ting 9.2 im JMX-Kapi­tel ist die Varia­ble home ohne Sicht­bar­keits­mo­di­fi­zie­rer, aber private final wäre kor­rek­ter. Oder Lis­ting 11.5 im Port­let-Kapi­tel:

private static String[] states = { … }
private static Set stateSet = new HashSet();
static {
  stateSet.addAll( Arrays.asList(states) );
}

Was soll das? Zunächst kann sta­tes und sta­te­Set final sein, aber davon abge­se­hen ist der static-Block über­flüs­sig denn der Kon­struk­tor von HashSet nimmt ger­ne eine Collection an. Bes­ser also – und auch groß­ge­schrie­ben, wie es die Auto­ren bei den ande­ren static-Varia­blen auch gemacht haben – wäre:

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

Es fal­len wei­ter­hin Klei­nig­kei­ten und Flüch­tig­keits­feh­ler auf, etwa bei

public class Widget {
  Widget() { }
  // ... widget methods ...
}

in dem der Kon­struk­tor nicht public ist, die Klas­se aber schon, und im Fol­gen­den

public Widget new Widget() {
  return new Widget();
}

was mit dem Leer­zei­chen auf kei­nen Fall ein gül­ti­ger Metho­den­na­me ist. In Kapi­tel 12 steht in Tabel­le 12.1 bei „Field“ in der rech­ten Zel­le „Working with method fiel­ds“, aber den Auto­ren ist beim Copy/Paste wohl das „method“ durch­ge­rutscht. Dann ist ifDoesntHaveclassTag falsch geschrie­ben, es soll­teifDoesntHaveClassTag hei­ßen, ein ande­res Mal stim­men die Ein­rü­ckun­gen nicht. Aber die­se Klei­nig­kei­ten kann man ver­zei­hen und haben kein gro­ßes Gewicht. Aber die Gret­chen­fra­ge ist: Soll­te man sich das Buch kau­fen wenn man nicht aus einem Alt­pro­jekt XDo­clet erbt? Die Ant­wort ist ein­deu­tig: Nö. Statt Meta­da­ten über Java­Doc zu set­zen sind es heut­zu­ta­ge Anno­ta­tio­nen der Stan­dard. XDo­clet hat den Dreh nicht bekom­men, sich zu einem all­ge­mei­nen Code-Gene­ra­tor zu mau­sern. XDo­clet 2 erwar­tet zwar die Meta­da­ten nicht mehr zwin­gend in den Java­Docs, son­dern kann durch sei­ne Modul­fä­hig­keit die Meta­da­ten prin­zi­pi­ell auch aus Anno­ta­tio­nen lesen, aber irgend­wie inter­es­siert sich kei­ner dafür; Das Pro­jekt kam nie aus der Pla­nungs­pha­se. Ein ande­rer Grund, dass XDo­clet heu­te kei­ne domi­nan­te Rol­le mehr spielt, ist der Weg­fall über­flüs­si­ger Klas­sen und Descrip­to­ren aus moder­nen Frame­works. XDo­clet mach­te EJB 2 ange­nehm, doch in EJB 3 ist XDo­clet ein­fach nicht mehr nötig, genau­so wenig wie für Hiber­na­te oder Web-Ser­vices. Scha­de um das Buch, ich mag XDo­clet aber seit auch Ser­v­let 3.0 auf Anno­ta­tio­nen setzt wird auch die web.xml zur Nuss­scha­le. Daher wird auch kein Buch-Update mehr geben und so blei­ben Ver­sio­nen für immer ein­ge­fro­ren: JBoss 3.2, Ser­v­let 2.3, Hyper­so­nic Data­ba­se statt HSQLDB, drei MBe­an-Typen (es sind nun 4, da Open MBe­an dazu­ge­kom­men ist) und MX4J lebt im Buch noch. Wie schnell­le­big die IT-Zeit doch ist. Dezem­ber 2010

Pro Jakar­ta Com­mons
Har­shad Oak, Apress, 1590592832, Febru­ar 2004, 304 Sei­ten

Har­shad Oak beschreibt in dem Buch die bekann­ten Jakar­ta Com­mons Biblio­the­ken. Nicht jede Funk­ti­on wird vor­ge­stellt, sodass das Buch die Java­Doc nicht ersetzt. Eher ver­sucht der Autor die Phi­lo­so­phie und Kern­kom­po­nen­ten zu ver­mit­teln. Es gibt immer wie­der kom­plett abge­bil­de­te Lis­tings, die man direkt in die IDE ein­set­zen und mit den ent­spre­chen­den Libs im Klas­sen­pfad direkt aus­füh­ren kann. Mich hät­te gefreut, wenn hin­ter den println()-Zei­len gleich die Aus­ga­be steht, so muss nicht man immer unter das Lis­ting schau­en – das geht bes­ser. Die Aus­wahl an The­men ist OK, nur sein Sty­legui­de ist zum Teil etwas schwach, wenn er etwa Varia­blen iVowelCnt oder iTestLen nennt. Auch Zei­len wie

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

über­ra­schen mich (mal wie­der). Und was ist das für eine Schreib­wei­se in "SELECT UserName as uName, AgE FROM USER"?

Updates wären natür­lich sehr schön. Java 5 spielt kei­ne Rol­le, und Java 1.4 wird als aktu­ell bezeich­net, sodass es NestableException einen grö­ße­ren Raum ein­nimmt, als es müss­te. An ande­rer Stel­le gibt es den Satz “The Dis­co­very com­po­nent depends on JDK ver­si­on 1.1.8 or hig­her”. Also wenn das nicht gege­ben ist… Auch Enum könn­te man sich natür­lich mit Java 5 spa­ren. Aber das ist eine all­ge­mei­ne Kri­tik auch an den Jakar­ta Com­mons, da kann der Autor nichts für. Heu­te könn­te man eine Rei­he on Ver­bes­se­run­gen vor­neh­men und auch Alter­na­ti­ven nen­nen. Im Bereich Date/Time etwa Joda-Time, bei Collec­tions natür­lichGoog­le Collec­tions, usw. Die Vali­da­tor-Klas­se macht mitt­ler­wei­le Java Beans Vali­da­ti­on, ein Stan­dard von Java EE 6, qua­si über­flüs­sig und Struts Vali­da­tor spielt heu­te kei­ne Rol­le mehr. Bei den Bea­nU­tils wäre der Hin­wei­se ange­bracht, dass man mit dyna­misch gene­rie­ten Byte­code schnel­le­re Lösun­gen rea­li­sie­ren kann als über Reflec­tion. Fürs Daten­bank-Poo­ling gibt es auch Alter­na­ti­ven, sie wären gut im Kapi­tel 6 auf­ge­lis­tet. Com­mons Log­ging ist auch nicht unpro­ble­ma­tisch, eine tie­fe­re Dis­kus­si­on hät­te der Autor brin­gen kön­nen. Und Thread-Pools könn­ten auch noch erwähnt wer­den. In Java 7 ersetzt Objects die Com­mons Klas­se ObjectUtils. Zusam­men­fas­sung: Fort­ge­schrit­te­ne Ent­wick­ler dürf­ten sich das Buch spa­ren kön­nen und kom­men mit der API-Doku­men­ta­ti­on – die sehr gut und mit vie­len Bei­spie­len bebil­dert ist – sehr weit. Eini­ge der Com­mons-Biblio­the­ken sind zudem heu­te ver­al­tet und spie­len in neu­es­ten Pro­jek­ten kei­ne gro­ße Rol­le mehr. Die span­nen­den und aktu­el­len The­men kom­men im Buch lei­der etwas zu flach weg. Mai 2010

The Com­ple­te Log4j Manu­al: The Relia­ble, Fast and Fle­xi­ble Log­ging Frame­work for Java
Ceki Gülcü. QoS.ch. ISBN 2970036908. 2003. 206 Sei­ten
Dürf­te wohl das Stan­dard­werk für die­se Log­ging-API sei. Kein Wun­der, ist doch der Autor des Buches auch die zen­tra­le Figur der Biblio­thek. Die ein­lei­ten­de Beschrei­bung hat man schon oft in ein­füh­ren­den log4j Wer­ken gele­sen — alles von die­sem Buch über­nom­men. Genau beschreibt Gülcü zur Kon­fi­gu­ra­ti­on vonlog4j die Eigen­schaf­ten in den Pro­per­ties-Datei­en und Ele­men­te in den XML-Doku­men­ten. Das glei­che gilt für die Ein­stel­lun­gen der Appen­der, etwa derRollingFileAppender oder DailyRollingFileAppender. Detail­liert wer­den die Imple­men­tie­rung eige­ner Log­ger und Fil­ter und von den Dia­gnostic Con­texts, die das Log­ging von ver­teil­ten Anwen­dun­gen erleich­tern, dar­stellt. Vor die­sem Buch habe ich davon noch nie was gehört. Im Zen­trum ste­hen hier Map­ped Dia­gnostic Con­texts (MDC) und Nested Dia­gnostic Con­texts (NDC). Auch geht der Autor auf die Log­ging API von Java 1.4 ein und auf Com­mon Log­gings. Hier beschreibt er die Unter­schie­de und die Schwie­rig­kei­ten. Nach mei­nem Geschmack hät­te ich mir eine hüb­sche Tabel­le mit den Unter­schie­den gewünscht, doch auch ohne wer­den dem Leser genug Vor­tei­le von log4j auf­ge­zählt. Novem­ber 2004