Allgemeine Java-Bücher, Einführungen

Java 1.5 Tiger: A Developer’s Note­book
David Flana­gan, Brett McLaugh­lin. O’Reilly. ISBN 0−596−00738−8. Juni 2004. 200 Sei­ten
Real­tiv schwa­ches Java 1.5 Buch, wel­ches wirk­lich nur die bekann­ten Fea­tures auf­zeigt. Schon die tute­go-Web­sei­te zu den Java 1.5 Ände­run­gen gibt mehr her als die­ses Buch. 2008

Java als ers­te Pro­gram­mier­spra­che — vom Ein­stei­ger zum Pro­fi
Joa­chim Goll, Cor­ne­lia Weiß, Frank Mül­ler. B.G. Teub­ner Ver­lag. ISBN 978–3519226420. 880 Sei­ten
Erscheint mir als akzep­ta­bles Uni-Buch. Vie­le gute Abbil­dun­gen. Objekt­ori­en­tie­rung „fühlt“ man aber nicht nicht wirk­lich. Klar, wird erklärt, was Ver­er­bung und Poly­mor­phie ist, aber das OOP-Bei­spiel soll­te schon durch­gän­gig sein. (Und dann wie­der ein dum­mes Bei­spiel, dass ein Stu­dent eine Per­son ist…) Eine neue Auf­la­ge ist ver­füg­bar. 2008

Hard­core Java
Robert Sim­mons. O’Reilly. ISBN 0−596−00568−7. März 2004. 344 Sei­ten
War­um tut mir O’Reilly das an? Ich set­ze es ohne Beden­ken auf Platz 1 in der Lis­te der Java-Bücher, die einen völ­lig ver­fehl­ten Titel tra­gen. Im Vor­wort wird noch groß ver­kün­det: „We’re tal­king about dif­fi­cult but extre­me­ly power­ful and use­ful pro­gramming tech­ni­ques like reflec­tion, advan­ced data mode­ling, advan­ced GUI design, and advan­ced aspects of JDO, EJB and XML-based web cli­ents. This uni­que book reveals the true wizard­ry behind the com­plex and often-mys­te­rious Java envi­ron­ment.“ und dann kommt nur Anfän­ger­stoff und nix von JDO, EJB oder XML. Dafür umso mehr Kin­der­gar­ten­the­men: Jede Klas­se ist von java.lang.Object abge­lei­tet, ein „if“ ver­trägt auch kom­ple­xe Anfra­gen mit ZWEI Bedin­gun­gen oder dass es einen ?-Ope­ra­tor gibt. Echt Hard­core! Des Wei­te­ren dekla­riert Fel­der in umständ­li­cher Syn­tax int[] AN_ARRAY = new int[] {1, 2, 3, 6, 9, 18, 36}; statt ein­fach nur int[] AN_ARRAY = {1, 2, 3, 6, 9, 18, 36}; Und schließ­lich 30 Sei­ten Aus­ein­an­der­set­zung von final. Die Namen der Color-Kon­stan­ten sind klein statt groß (gibt es „erst“ seit Java 1.4) geschrie­ben, und war­um der Autor in dem Calen­dar-Bei­spiel aus­drück­lich nach GMT fragt, ist eben­falls son­der­bar, denn für das Bei­spiel spielt das über­haupt kei­ne Rol­le:

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

Im nächs­ten Kapi­tel über immu­ta­ble kommt natür­lich der Hin­weis auf String (immu­ta­ble) und Point, Date, String­Buf­fer (nicht immu­ta­ble), aber wert­vol­le Hin­wei­se, etwa das immu­ta­ble-Typen die Ent­wick­lung von mul­ti­the­a­ded-Anwen­dun­gen mas­siv erleich­tern und immu­ta­ble Objek­te gut in einen Pool pas­sen (wie eini­ge Wrap­per-Objek­te in Java 5) wer­den unter den Tep­pich gekehrt. Immer­hin erwähnt er die Unmo­di­fied-Wrap­per. Wei­ter zum nächs­ten Hard­core-The­ma, der Collec­tion-API. Mr. Sim­mons schreibt: „…code is an examp­le of a good inter­face-based tech­ni­que:“

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

Der Objekt­typ von some­Set soll­te wohl Set statt Hash­Set sein. Und war­um ist in dem Bei­spiel die Metho­de gera­de pro­tec­ted? Und some­Set paket­sicht­bar? Da steckt ver­mut­lich Hard­core Java Design-Erfah­rung im Code. Na ja, dann hakt das Kapi­tel noch mal eben alle Hard­code-Collec­tion-Klas­sen ab. Dass Robert fail-fast von Ite­ra­to­ren erklärt, ist super, aber dann der nächs­te Rück­schlag bei set.add(new String("p->" + element)). Was soll denn das hei­ßen? Das nächs­te Kapi­tel heißt Excep­ti­on-Hand­ling (in wel­chem Java-Ein­füh­rungs­buch steht das bit­te schön nicht?) und der Hin­weis, dass final­ly eine gute Stel­le ist, um Daten­bank­ver­bin­dun­gen zu schlie­ßen. Das fol­gen­de Kapi­tel ist noch viel här­ter. Es geht um inne­re Klas­sen. Jetzt ist es an der Zeit, sich jeden Satz ganz genau anzu­schau­en und sich hoch zu kon­zen­trie­ren. Radio aus, Fern­se­her aus, Com­pu­ter aus. Wei­ter zum nächs­ten Ham­mer­the­ma – Kon­stan­ten und Inter­na­tio­na­li­sie­rung. Dass Robert auch Klam­mern kennt, zeigt er in Anwei­sun­gen wie die­ser:

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

Um viel­leicht unge­nau­en Pi-Bele­gun­gen von Sun über Math.PI vor­zu­beu­gen, ist es auch sinn­vol­ler, gleich selbst PI vor­zu­be­le­gen: public static final double PI = 3.141;. Ist viel viel bes­ser! Im Kapi­tel wer­den auch Bit-Fel­der vor­ge­stellt inklu­si­ve der Bit-Ope­ra­to­ren. Bei den anschlie­ßen­den Auf­zäh­lun­gen und Kon­stan­ten-Objek­ten baut der Autor dann erst ein­mal das Java 5 enum nach, bis er schluss­end­lich im letz­ten Kapi­tel auch zu Java 5 kommt. Dann kommt aber doch noch ein inter­es­san­ter Absatz über read­Re­sol­ve() bei der Seria­li­sie­rung. Immer­hin hat Robert ver­stan­den, dass es Klas­sen­la­der gibt: „You may think that sin­ce the con­stant object is final and sta­tic, this will gua­ran­tee that only one ins­tan­ce of each con­stant object will be in memo­ry. I used to think the same thing until I was blindsi­ded by a vicious bug in a gene­tic rese­arch sys­tem.“ Impres­si­ve! Im 8. Kapi­tel geht’s um Daten­mo­del­lie­rung. Kein Java-The­ma und auch nur ein paar Sei­ten. Der Ansatz: „Unter­strei­che alle Nomen und du hast Klas­sen, unter­strei­che alle Ver­ben und du hast Metho­den“ darf auch nicht feh­len. So hat Robert sicher­lich gro­ße Enter­pri­se Sys­te­me model­liert. (Aber DDD war damals wir­lich noch was neu­es.) Kapi­tel 9 hat Reflec­tion zum The­ma und etwas zum java.beans Paket. Sei­ne Lust, an alle mög­li­chen fina­len Varia­blen auch final dran­zu­schrei­ben, sinkt. Kapi­tel 10 kommt auf Pro­xies zu spre­chen, und dass die bei CORBA und RMI vor­kom­men. Nach­dem ein selbst­ge­bau­ter Pro­xy sich vor­stel­len darf, kommt es doch noch zu Ein­satz vom InvocationHandler/Proxy. Jetzt wird es lang­sam inter­es­sant. Kapi­tel 10 spricht von schwa­chen Refe­ren­zen. Er imple­men­tiert ein

public class WeakHashSet extends AbstractSet implements Set

(war­um steht hier imple­ments Set?) und schreibt einen Weak-Lis­tener. Solch ein Kon­strukt ist ins­be­son­de­re in Swing-Anwen­dun­gen sehr nütz­lich, doch hier hät­te ich den Hin­weis gut gefun­den, dass etwa die Ope­nI­DE, also Net­Be­ans, hier schon etwas anbie­tet. Wo jetzt ande­re „Hardcore“-Bücher ein­stei­gen ist sei­nes, oh scha­de, schon zu Ende. Das war eigent­lich das letz­te Kapi­tel! Denn Kapi­tel 12 ist das Abschluss­ka­pi­tel mit Java 5 und geht auf die Neue­run­gen ein. Doch sei­en wir ehr­lich: Har­te Nüs­se wie Gene­rics las­sen wir uns viel lie­ber von einem ech­ten Crack, von Joshua Bloch, in sei­nem Buch erklä­ren. Dann müs­sen wir uns nicht Bei­spie­le wie die­ses hier anschau­en:

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

Typ­va­ria­blen soll­ten immer nur aus ein­zel­nen Groß­buch­sta­ben bestehen. Bei einer Dekla­ra­ti­on wie Type getVa­lue() sieht sonst Type wie ein ordi­nä­ren Java-Typ aus. Und war­um wird value mit null initia­li­siert. Das ist doch klar, dass die JVM das mit null belegt. Was zeigt das Buch? Immer­hin das O’Reilly den Mut hat, die schlech­ten Bewer­tun­gen auf der Web­sei­te ste­hen zu las­sen und nicht zu löschen. Mei­ne Hoch­ach­tung. Bei Ama­zon sind die Bewer­tun­gen aber noch ehr­li­cher. Mut wird O’Reilly erst dann wirk­lich bewei­sen, wenn sie a) den Titel umfor­mu­lie­ren, b) sich einen neu­en Autor suchen, der das Buch umschreibt bzw. erwei­tert oder c) – die bes­te Opti­on für jetzt – das Buch aus dem Sor­ti­ment nimmt. 4 Jah­re nach Erschei­nen wird’s Zeit dafür. Mai 2008

Java/J2EE Job Inter­view Com­pa­n­ion — 400+ Ques­ti­ons & Ans­wers
Arul­ku­maran Kum­a­ras­wa­mi­pil­lai, Sivay­ini Arul­ku­maran. Lulu.com. ISBN 1411668243. April 2007. 355 Sei­ten
Es han­delt sich um ein inter­es­san­tes Buch, wel­ches ich in die­ser Form noch nicht gele­sen habe. Meist dreht es sich ja um Anwen­dungs­de­sign oder har­te Tech­no­lo­gi­en, aber ein Buch, wel­ches für Java-Ent­wick­ler mög­li­che Bewer­bungs­fra­gen sam­melt, ist mir neu. Daher soll­te das Werk auch von zwei Sei­ten beleuch­tet wer­den: Vom Inter­view­er und vom Inter­view­ten. Bei­de Grup­pen erhal­ten mög­li­che Stan­dard­fra­gen zu diver­sen The­men aus Java SE, Java EE (+Hiber­na­te +Spring) sowie Anwen­dungs­de­sign. Das Niveau wech­selt zwi­schen „Was ist der Unter­schied zwi­schen String und String­Buf­fer?“ und „Erklä­re Inner Join und Outer Join.“ Bei­de Par­tei­en erhal­ten aus­rei­chen­de Ant­wor­ten, wobei das Buch nur kur­ze Erklä­run­gen lie­fert und auf brei­te Aus­schwei­fun­gen ver­zich­tet; sonst könn­te leicht ein 2000 Sei­ten star­ker Wäl­zer dar­aus wer­den. Die Fra­gen sind gut gemischt und decken opti­mal das Stan­dard­wis­sen jedes Ent­wick­lers ab. Trotz des Lobes kann die Erwäh­nung eini­ger Feh­ler nicht unter­blei­ben. Ein Bei­spiel zum The­ma Varags: „The type must be Object and it must be the last argu­ment or the only argu­ment to the method.“ Natür­lich kann jeder Typ bei Varags ver­wen­det wer­den, int... genau­so wie String.... Hin­zu kom­men noch ein paar Klei­nig­kei­ten, wie \n statt %n in printf(), klein geschrie­be­ne Enum-Kon­stan­ten, String-Kon­ka­te­na­tio­nen im SQL-State­ment für varia­ble Tei­le statt Pre­pa­red-State­ment und nicht erreich­ba­rer Pro­gramm­code beim Schlie­ßen von JDBC-Con­nec­tions, wenn es vor­her eine Excep­ti­on gab. Den­noch alles in allem ein gutes Buch zur Vor­be­rei­tung und auch zum Auf­fri­schen des Java-Wis­sens für Ent­wick­ler, die schon ein paar Jah­re Java pro­gram­mie­ren. Mai 2008

Das Java Code­book
Mar­cus Wie­der­stein, Mar­co Skul­schus, Mark Don­ner­mey­er, Dirk Bro­der­sen, Ben­ja­min Rusch. Addi­son-Wes­ley. ISBN 3−8273−2059−3. 2003. 858 Sei­ten
Pro­gramm­ab­schnit­te, sog. Snip­pets, gibt es im Inter­net genug (wir wäre es alter­na­tiv mit dem Java-Alma­nac?) und wer eine Such­ma­schi­ne bedie­nen kann, wird immer, ja immer, die Biblio­thek oder den Quell­code-Schnipp­sel fin­den, die er sucht. Um so erstaun­li­cher fin­de ich es, wenn Ver­la­ge Quell­code-Koch­bü­cher ver­öf­fent­li­chen, ob sie nun Code­book oder Cook­book hei­ßen. Ernst­haft: Wer eine Klas­se zur Bruch­rech­nung sucht oder ein Bei­spiel­pro­gramm zum Auf­bau eines Swing-Fens­ters, geht sicher­lich nicht zum Regal, sucht im Index nach „Bruch“ und holt sich dann die Klas­se von der CD. Daher die Fra­ge — ist ein Buch wie „Das Java Code­book“ not­wen­dig? Das Posi­ti­ve zuerst: Die Kapi­tel über regu­lä­re Aus­drü­cke und App­lets (Daten im Coo­kie spei­chern, Uploads, App­let-Kon­ver­ter für Tags), die klei­nen Bei­spiel­pro­gram­me, in denen man etwa über ein BufferedImageOp.filter Bil­der heller/dunkler macht, sowie Hin­wei­se zur Trans­pa­renz und der Index fin­de ich pri­ma. Eigent­lich sind Bücher mit Quell­code gut, denn Soft­ware-Ent­wick­ler lesen im All­ge­mei­nen zu wenig. Das Stu­di­um von Quell­code hilft jedem Ent­wick­ler, neue Idio­me zu ler­nen und sei­ne Fähig­kei­ten zu ver­bes­sern. Je nach Schwer­punkt des Buches lernt man wei­te­re Mög­lich­kei­ten der Stan­dard­bi­blio­thek ken­nen oder neue Open-Source-Biblio­the­ken. Soweit die Mög­lich­kei­ten guter Code­books. Lei­der hat das Java Code­book dann doch die eine oder ande­re Schwach­stel­le, sodass man Soft­ware-Ent­wick­lern viel­leicht doch bes­ser direkt zur Goog­le-Suche raten soll­te. (Immer­hin gibt es das Buch als PDF.) Die Pro­ble­me im Detail: Die Klas­se CalcExample dekla­riert drei Varia­blen (Sicht­bar­keit könn­te auch anders sein), doch ver­gisst, dass es ZERO, ONE, TEN schon in Big­De­ci­mal gibt:

static final BigDecimal ZERO = new BigDecimal(0);
static final BigDecimal ONE = new BigDecimal(1);
static final BigDecimal FOUR = new BigDecimal(4);

In ande­ren Bei­spie­len gefällt mir die Schreib­wei­se der Fel­der nicht. Eini­ges ist nach der Bau­art String []array, also Typ, Leer­zei­chen, Varia­blen­na­me auf­ge­baut. Das habe ich nach 11 Jah­ren Java hier zum ers­ten Mal gele­sen. Zumal sich die Auto­ren hier uneins zu sein schei­nen, denn sie ver­wen­den auch String[]. Die fünf Auto­ren des Buchs fol­gen dem­nach kei­ner ein­heit­li­chen Coding-Kon­ven­ti­on. Ein wei­te­res The­ma betrifft die Metho­den­na­men: Über­wie­gend wer­den eng­li­sche Bezeich­ner (set­Num­ber, less100, …) gebraucht, doch las­sen sich inner­halb eines Bei­spiels Ver­mi­schun­gen mit deut­schen Varia­blen­na­men ent­de­cken, wie das Feld ZEHN. Eini­ge Auto­ren mögen (immer noch) die Klas­sen Hash­t­a­ble und Vec­tor, ande­re nut­zen doch bes­ser List und Map — hat denn kei­ner der Auto­ren die ande­ren Kapi­tel gele­sen und kom­men­tiert? Bei den Daten­struk­tu­ren fra­ge ich mich wirk­lich, was denn arrayList.add(new String(new java.util.Date().toString())); für eine Anwei­sung sein soll. Und war­um wird ein Stack noch mal neu imple­men­tiert? OK, der Ori­gi­nal-Stack erbt von Vec­tor, was vom Design total ver­pfuscht wur­de, aber dann könn­te man doch immer noch den neu­en Stack so imple­men­tie­ren, das er an den alten Stack dele­giert, anstatt alle Ope­ra­tio­nen kom­plett mit einer Array­List neu zu imple­men­tie­ren. (Und dann noch die frag­wür­di­ge Metho­de search() zu über­neh­men.) Eine wei­te­re Schwach­stel­le, die ich in der Insel wei­test­ge­hend ver­su­che zu ver­mie­den, sind Win­dows-spe­zi­fi­sche Pfad­an­ga­ben, wie etwa bei new FileOutputStream("c:\\buecher.ser"). Bei IO-Bei­spie­len fehlt oft das close() im finally. Vor allem bei HTTP-Ser­vern ist das kri­tisch. Im JSP-Kapi­tel fin­det sich plötz­lich ein JDBC-Clo­se im finally; also hat es nicht jeder der Auto­ren ver­ges­sen. Fra­ge: Was gibt die­ses Pro­gramm bei Argu­men­ten auf der Kom­man­do­zei­le 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 Zer­ti­fi­zie­rungs­fra­ge statt eines sinn­vol­len Code­bei­spiels, denn ist die Anzahl der Argu­men­te klei­ner 1, gibt es kei­ne Argu­men­te und die Schlei­fe ist nutz­los. Genau­so falsch ist der Satz „JDBC benutzt dabei die Inter­faces Con­nec­tion, Dri­ver und Dri­ver­Ma­na­ger.“ Scha­de, denn Dri­ver­Ma­na­ger ist eine Klas­se. Soll­te es auch, denn aus die­ser Zen­tra­le erhält man durch die sta­ti­sche Metho­de get­Con­nec­tion() eine Ver­bin­dung. Im Anhang fin­den sich dann noch ein paar Dre­her in der Groß-/Klein­schrei­bung. Z. B. begin­nen eini­ge Bezeich­ner in der Tabel­le „Java Nati­ve Inter­face Typen“ mit Groß­buch­sta­ben. Bes­ser wären „int“ statt „Int“ sowie „void“ statt „Void“ usw. Ähn­li­ches gilt für Jscroll­Pa­ne, was zu JScroll­Pa­ne wer­den soll­te. Unter „Rela­tio­na­le Ope­ra­to­ren“ fin­det sich fol­gen­der Satz bei ==-Ope­ra­tor: „a == b ergibt true, wenn a gleich b ist. Han­delt es sich bei a und b um Refe­renz­ty­pen, so ist der Rück­ga­be­wert dann true, wenn bei­de auf das­sel­be Objekt zei­gen.“ Wir soll­ten den Son­der­fall a = b = NaN aber nicht Außer­acht las­sen, denn gera­de dann ist a = b, aber das Ergeb­nis nicht true. In der Tabel­le „Klas­sen­ob­jek­te für den pri­mi­ti­ven Daten­typ“ soll­te Void bes­ser nicht auf­tau­chen, da es sich nicht um einen pri­mi­ti­ven Daten­typ han­delt. Oder Void ste­hen las­sen, aber die Über­schrift anpas­sen. Eini­ge Kri­tik­punk­te betref­fen die Aus­wahl der Klas­sen. Die Klas­se Frac­tion soll­te viel­leicht bes­ser einer bekann­ten Open-Source-Biblio­thek ent­stam­men und die Matri­zen sowie der umfang­rei­che Quell­code nicht unbe­dingt abge­bil­det wer­den. Für CSV-Datei­en wären popu­lä­re Stan­dard-Klas­sen sinn­vol­ler. Der Tipp 186 für Timer soll­te die­sen nicht selbst imple­men­tie­ren, son­dern die zwei (!) Timer-Klas­sen der Java-Lib vor­stel­len. Da ein Code­book grund­sätz­lich eine unend­li­che Sache ist, könn­ten wei­te­re Snip­pets ein­ge­bracht wer­den. Bei den Zufalls­zah­len wäre z. B. Secu­reR­an­dom gut unter­ge­bracht. Das Bei­spiel FindIn­File, was hän­disch nach einem String in einer Datei sucht, lässt sich viel effek­ti­ver mit NIO (mit Stan­dard-Bei­spiel von Sun) lösen. Das NIO-Kapi­tel kommt mit nur zwei Bei­spie­len daher (Datei kopie­ren und File-Lock). Das ist eine mage­re Aus­beu­te. Spä­ter kommt noch ein NIO-Ser­ver dazu. Der Ver­weis auf eine ein­fa­che NIO-Biblio­thek (wiehttp://mina.apache.org/) wäre dann wün­schens­wert. Um ein Fens­ter mit­tig zu posi­tio­nie­ren, muss man nicht rech­nen, hier reicht eine Java-Funk­ti­on. Wenn es sich schon um ein Java 1.4 Buch han­delt, dann soll­te ImageIO Gra­fi­ken laden. Die Swing-Bei­spie­le sind rela­tiv unspek­ta­ku­lär. Hier wäre es wohl sinn­vol­ler statt „wie erzeu­ge ich einen But­ton“ oder „wie etwas mehr mit den Model­len zu machen“, einen Datei­baum in ein JTree zu set­zen. Und sti­lis­tisch wert­voll ist der Hin­weis mit der JDBC-Ver­bin­dung in einem JSP-Tag sicher nicht. Und wo sind die DAOs? Bei JMS stimmt es zwar grund­sätz­lich, dass in einer Tabel­le bei Pro­gram­mier­spra­chen­un­ab­hän­gig­keit „Nein“ steht und bei HTTP „Ja“, doch all­ge­mein­gül­tig ist das nicht. Für ActiveMQ gibt es ein stan­dar­di­sier­tes Pro­to­koll­for­mat (Open­Wire) und APIs für diver­se ande­re Pro­gram­mier­spra­chen. Das glei­che gilt auch für IBMs WebS­phe­re MQ (frü­her MQSe­ries) — sicher­lich eines der bes­ten MOMs -, das hete­ro­ge­ne Platt­for­men ver­bin­det. Einen XML-Par­ser über die Anwei­sungorg.apache.xerces.parsers.DOMParser parser = new org.apache.xerces.parsers.DOMParser(); statt über JAXP zu erfra­gen ist nicht schön son­dern fast grob fahr­läs­sig. Zudem haben auch die JAXP-Par­ser Fea­tures, obwohl die String-Ken­nun­gen dann immer ein wenig anders aus­se­hen. Zu Tipp 196: Wann immer man sich mit getGraphics() einen Gra­fik-Kon­text holt, soll­te man ihn auch wie­der frei­ge­ben. Die­ser Hin­weis fehlt lei­der in den Bei­spie­len. Farb­kon­stan­ten soll­ten groß geschrie­ben sein, also Color.WHITE, statt Color.white, zumin­dest seit­dem Sun die­se Kon­ven­ti­on in Java 1.4 ein­ge­führt hat. August 2007

Bit­ter Java. The les­sons taught by ser­ver-side Java anti­pat­terns  
Bruce A. Tate. Man­ning. ISBN 193011043X. 2002. 368 Sei­ten
Das Buch habe ich schon rela­tiv lan­ge und vor ein paar Jah­ren warf ich schon ein­mal einen Blick dar­auf. Ich hat­te es wie­der zur Sei­te gelegt, da es mich damals nicht so ange­macht hat und die ein­füh­ren­den Geschich­ten mich lang­weil­ten. Da das Buch jetzt ›raus‹ soll­te, nahm ich es mir noch etwas genau­er vor. Kurz gesagt: Es lang­weilt mich immer noch. Im mei­nen Augen ist es ein Buch mit sehr wenig Inhalt geseg­net und dazu noch mit Lis­tings, die unglaub­lich flau sind. Didak­tisch bin ich kein Freund der Stra­te­gie erst-mal-alles-falsch-zei­gen-und-dann-100-Sei­ten-wei­ter-kor­ri­gie­ren. Das Buch basiert auf der Idee. Und so wun­dert man sich als Leser kapi­tel­wei­se, war­um denn zum Bei­spiel Daten­bank­ver­bin­dun­gen nicht in einem final­ly geschlos­sen wer­den; das klärt erst das Kapi­tel 7.3.2 auf. Eben­falls Daten­ban­ken­ver­bin­dun­gen: Sie wer­den immer wie­der auf- und abge­baut, obwohl das die größ­te Per­for­mance gibt. Scha­de, dass das erst spä­ter in Kapi­tel 7.2.3 erklärt wird. Dann wäre aber eine Nen­nung eini­ger Open-Source Con­nec­tion-Pools nicht falsch. Quer durch vie­le Lis­tings – nicht alle – fin­den sich Daten­struk­tu­ren wie Vec­tor oder Hash­t­a­ble, in eini­gen ande­ren wie­der­um die Type der Collec­tion-API. Über­haupt ent­wi­ckelt Bruce vie­les selbst, etwas das Cache-Manage­ment mit einer Hash­t­a­ble. War­um hier kei­ne Open-Source Lösun­gen genannt wer­den, ver­ste­he ich nicht. Das glei­che auch bei einem selbst ent­wi­ckel­ten Con­trol­ler bei JSPs. Dass JSP wenig/kein Java-Quell­code ent­hal­ten soll­te, müs­se heu­te wirk­lich jedem Ent­wick­ler klar sein; aber sei­ne Lösung, die Java EE Pat­tern selbst zu imple­men­tie­ren fin­de ich kei­ne gute Idee. Sti­lis­tisch gibt es wei­te­re Schwä­chen, extrem viel im Bereich Excep­ti­on-Hand­ling. Hier weiß ich über­haupt nicht, was Bruce sich dabei gedacht hat. Eini­ge Bei­spie­le: War­um wird zum Öff­nen einer Daten­bank­ver­bin­dung mit vor­an­ge­hen­demClass.forName() ein Throwable gefan­gen? War­um wer­den gleich zwei Run­ti­meEx­cep­ti­on nach oben gelei­tet wie in getAut­hor und spä­ter nach mal in getNumber():

public String getAuthor(int index) throws IndexOutOfBoundException, ArrayIndexOutOfBoundException{
 return (String) author.elementAt( index );
}

Dann wer­den Typen aus dem java.lang-Paket, wie im Kapi­tel 6.3.1 mit catch(java.lang.Throwable) voll qua­li­fi­ziert; und immer wie­der wird Thro­wa­ble auf­ge­fan­gen. Und ich kann auch nicht sehen, war­um es beim Erzeu­gen eines Punk­tes und Auf­ru­fes drei­er Set­ter zu einer Aus­nah­me kom­men kann, die man abfängt. Danach noch mal das glei­che mit einem Text­Field. Und war­um AWT und nicht Swing?

ivjTest = new java.awt.Button();
ivjTest.setName( ... );
ivjTest.setBounds( ... );
ivjTest.setLabel( ... );

Oder auch die­ses Excep­ti­on-Kon­st­ukt:

public static void main( ... ) {
 try { ... }
 catch ( Exception e ) {
  throw new RuntimeException( e.toString() );
 }
}

Wei­te­re Bei­spie­le las­sen an den Kor­rek­tur­le­sern zwei­feln. Der Schlei­fen­zäh­ler ist i, aber im Rumpf wird er mit _i genutzt. Dann eine Zäh­ler-Klas­se:

class counter
{
 public static Integer count = 0;
 public void count() {
  Integer temp = count;
  temp = temp + 1;
  count = temp;
 }
}

Ganz davon abge­se­hen, dass man Klas­sen groß­schrei­ben soll­te, kann man (jeden­falls nicht bist Java 5) mit Wrap­per-Objek­te nicht rech­nen und auch nicht mit 0 initia­li­sie­ren. Und war­um wer­den Objekt­va­ria­blen mit null initia­li­siert, wie bei private D d_ = null;? Einen Knül­ler fand ich hän­disch kon­ka­te­nier­te SQL-Anwei­sun­gen, statt gleich Pre­pa­red­State­ments zu ver­wen­den: wie "SELECT subject, author, board, number from posts where board='" + getBoard() + "' and parent=0" oder noch „bes­ser“

"INSERT INTO POSTS values ('"
 + getSubject()
 + "' (select max(number) from posts) + 1, '"
 + getAutor()
 + "', '"
 + getPostText()
 + "', current timestamp, "
 + getParent()
 + ", '"
 + getBoard()
 + "'");

Dann wer­den erst mal wie­der alle EJB-Basics raus­ge­kramt: Es muss ein Remo­te-Inter­face geben, dann ein Home, Deploy­ment-Deskrip­tor, usw. Was es hier zu Ver­bes­sern gibt, ist lächer­lich: Alle dekla­rier­ten Ent­i­ty-Beans sind remo­te und die Ver­bes­se­rung – welch Wun­der – eine Fas­sa­de. Aber das dies kei­ne gute Idee ist, müss­te nun eigent­lich jedem EJB-Ent­wick­ler gekannt sein – und unter EJB 3 glück­li­cher­wei­se nicht mehr mög­lich. (Merk­wür­dig ist aber schon, dass eine Web-Anwen­dung remo­te auf EJBs zugreift, aber las­sen wir uns auf die­se Annah­me ein.) Und ver­nich­ten­de Aus­sa­gen über CMP gefal­len mir so pau­schal nicht: „For EJBs, the Gol­den Ham­mer is usual­ly the ent­i­ty bean with con­tai­ner mana­ged per­sis­tence. This is also the EJB clas­si­fi­ca­ti­on with the most over­head. If every object in our model is a con­tai­ner-mana­ged ent­i­ty bean, we might want to hun­ker down behind the desk to pre­pa­re for the delu­ge of custo­mer com­p­laints about per­for­mance.“ In den JSPs gibt es for-Schlei­fen statt Ite­ra­tor-Tags. Der Rest sind dann ein paar Coding-Con­ven­ti­ons; nur schreibt man übli­cher­wei­se kei­nen Dop­pel­punkt hin­ter das Java-Doc-Tag @author. Dann schnell noch Wie­der­ho­lun­gen der Java-Sicht­bar­keit. Wer weiß als Ent­wick­ler nicht, was public, pro­tec­ted, … bedeu­tet? Per­for­mance-Tipps wie: Hal­te in Schlei­fen die red­un­dan­ten Berech­nun­gen raus sind an sich gut, aber das Bei­spiel for ( int i=0; i < collection.size(); i++) ist rela­tiv wert­los – die Metho­desize() kann Hot­Spot leicht inli­ne set­zen. Da gibt es drin­gen­de­re Pro­ble­me. Die Stil-Regel ›Typi­cal­ly, import state­ments should import java.util.* rather than java.util.Vector‹ to make main­tai­na­bi­li­ty simp­ler.‹ gefal­len mir über­haupt nicht. Die Anzahl der Import ist sehr wich­tig, um etwas über die Anzahl Abhän­gig­kei­ten her­aus­zu­fin­den – sie soll­ten nicht zu groß sein. Wenn, dann ist das ein Indiz dafür, dass der Typ ›zu viel macht‹. Eine Inter­es­san­te Idee ist, Feh­ler mit 8 Ein­hei­ten ein­zu­rü­cken, den Rest aber mit 4. Das muss ich mir optisch ein­mal anschau­en. In der Sum­me: Die Infos bekommt man bes­ser, etwa in einem Pat­tern-Buch, Buch über Per­for­mance oder Stil-Buch. August 2007

Java Secrets
Elliot­te Rus­ty Harold. IDG Books. ISBN 0764580078. 1997
Die Secrets sind zum Teil wirk­li­che Secrets, aber nicht, weil die ers­ten Kapi­tel über „Pri­mi­ti­ve Data Types“, „Clas­ses, Strings, and Arrays“, „App­lets“, „The Java Vir­tu­al Machi­ne“ han­deln, son­dern wegen dem Kapi­tel „The Sun Clas­ses“. Harold stellt vie­le der inter­nen sun-Klas­sen wie sun.misc.Queue, sun.misc.Sort, sun.misc.CRC16, sun.misc.BASE64Encoder/sun.misc.BASE64Decoder, sun.net.smtp.SmtpClient, sun.net.ftp.* vor. Das ein­zig merk­wür­di­ge war die Aus­sa­ge „JDBC stands for ‚Java Data­Ba­se Con­nec­tivi­ty‘“. Mai 2007

Java Soft­ware Solu­ti­ons: Foun­da­ti­ons of Pro­gram Design
John Lewis, Wil­liam Lof­tus. Addi­son-Wes­ley. ISBN 0201571641. 1997. 857 Sei­ten 
Mei­ne ers­te Auf­la­ge beschreibt erst Java 1.1, aber wenn ich den­ke, dass es das Buch auch in einer Java 5 Auf­la­ge gibt, kann man das Buch für Stu­den­ten emp­feh­len. Zwei­far­big gedruckt. Zum Teil didak­tisch mehr­wür­di­ge Rei­hen­fol­gen, aber das tut nicht unbe­dingt einen Abbruch. John Lewis hat unter http://duke.csc.villanova.edu/jss1/ eine Web­sei­te für die 4. Auf­la­ge, auf der er Din­ge wie Foli­en abge­legt hat. Mai 2007

Java Stan­dard Libra­ries. Java 2 Collec­tions Fram­work und Gene­ric Collec­tion Libra­ry for Java
Mar­kus Gum­bel, Mar­cus Vet­ter, Car­los Car­de­nas. Addi­son-Wes­ley. ISBN 3827316359. 518 Sei­ten
Recht schö­nes Buch. Zwar auf dem Stand von Java 1.3, sodass die neu­en Daten­struk­tu­ren ins­be­son­de­re aus Java 5 und Gene­rics feh­len und man sich die Gene­ric Collec­tion Libra­ry for Java (JGL) heu­te schen­ken kann, aber den­noch ein schö­ner Ein­steig. Sehr aus­führ­lich ist der Ver­gleich mit der C++ STLApril 2007.

Java Lan­guage Refe­rence
Mark Grand. O’Reilly. ISBN 1−56592−204−2. 448 Sei­ten
Alter­na­ti­ve Doku­men­ta­ti­on zur Java Sprach­be­schrei­bung mit net­ten Dia­gram­men für die Sprach­syn­tax (rail­road dia­grams). Es gab ein Update von Java 1.0 auf Java 1.1 (für die inne­ren Klas­sen), aber danach gab es kei­ne Buch-Updates mehr. Febru­ar 2007

Java 6 Platt­form Revea­led
John Zukow­ski. APress. ISBN 1590596609. 220 Sei­ten
Ein frü­hes Buch (Juni 2006) zu Java 6, aber es zeigt alle wesent­li­chen Eigen­schaf­ten der neu­en Ver­si­on. Sehr gut gefal­len hat mit die Beschrei­bung von CookieHandlerCookieManager & Co. KG, etwas, was ich noch nie ordent­lich erklärt gefun­den habe. Der ein­zi­ge Feh­ler, der mir auf­ge­fal­len ist, befin­det sich auf Sei­te 111, wo eine Varia­ble statt rs (für ResultSet) fälsch­li­cher­wei­se st heißt. Eine prä­zi­se­re Beschrei­bung für Web Ser­vices und JAXB lie­fert das Buch lei­der nicht — nur ein paar Stan­dard-Bei­spie­le und eine schlaf­fe Auf­zäh­lung der Anno­ta­tio­nen — aber dafür gibt es ja ande­re Bücher aus der Ecke der Java EE Lite­ra­tur. Auch StAX ist nicht son­der­lich prä­zi­se und spä­te­ren Neue­run­gen, wie Java DB oder Grou­pLay­out fin­den kei­ne Erwäh­nung. Das glei­che gilt für neue Funk­tio­nen copySign()getExponent(),nextAfter()nextUp()scalb() aus Math/StrictMath. Eigent­lich wäre jetzt Zeit für ein Buch-Update. Janu­ar 2007

Java. Die Spe­zi­fi­ka­ti­on der vir­tu­el­len Maschi­ne
Tim Lind­holm, Frank Yel­lin. Addi­son-Wes­ley. 1. Auf­la­ge. ISBN 3−8273−1045−8. 1987. 450 Sei­ten
Das Buch ist sicher­lich kein packen­der Thril­ler, doch glau­be ich, jeder soll­te die Spe­zi­fi­ka­ti­on der JVM ein­mal gele­sen haben. (Man muss dazu nicht das Buch kau­fen, son­dern kann alles online lesen.) Die Über­set­zung ist zum Teil etwas merk­wür­dig und eini­ge Begrif­fe inter­es­sant. (Final­ly-Blö­cke hei­ßen ›Abschluss­rou­ti­nen‹ und die Über­setz­ter deut­schen ›modi­fi­zier‹ mit ›Modi­fi­ka­to­ren‹ ein, wäh­rend ich sie lie­ber ›Modi­fi­zie­rer‹ nen­ne.) Lei­der pas­sier­te ein Feh­ler auf der ers­ten Sei­te der ers­ten Auf­la­ge, dass das Team Mary Campione/Karthy Wal­rath das Buch geschrie­ben haben soll. Und sol­che Feh­ler tau­chen auf, obwohl gleich 7 Per­so­nen das Buch über­setzt haben. Din­ge, die ich in die Insel noch auf­neh­men soll­te sind Laden/Verifizieren/Binden. Mir ist auch noch nie eine sta­ti­sche Metho­de class­Fi­na­li­ze() auf­ge­fal­len, die eine JVM beim Ent­fer­nen (unloa­ding) von Klas­sen auf­ge­ru­fen könn­te. (Sun schreibt dazu unter http://java.sun.com/docs/books/jls/class-finalization-rationale.html: ›Eli­mi­na­ting this fea­ture has no effect on exis­ting pro­grams, sin­ce it was unim­ple­men­ted.‹) Das inter­es­san­tes­te Kapi­tel zum Ver­ständ­nis ist sicher­lich ›Das Über­set­zen für die vir­tu­el­le Maschi­ne‹ auf knap­pen 26 Sei­ten. Die ers­ten 50 Sei­ten haben nichts mir der JVM an sich zu tun, son­dern fin­den sich wie das Kapi­tel ›Threads und Sper­ren‹ auch in der Sprach­re­fe­renz. Man hät­te auf die­se 70 Sei­ten eigent­lich ver­zich­ten kön­nen. Janu­ar 2k, Dezem­ber 2006

Dis­tri­bu­t­ed Java 2 Plat­form Data­ba­se Deve­lop­ment
Ste­wart Birn­am. Pren­ti­ce Hall. ISBN 0−13−026861−5. 276 Sei­ten. 2001
Von allem ein biss­chen wie das Buch ›Advan­ced Pro­gramming for the Java 2 Plat­form‹. Inter­es­san­ter Über­blick für die­je­ni­gen, die im Jahr 2000 leben. Novem­ber 2006

Java Nati­ve Inter­face: Programmer’s Gui­de and Spe­ci­fi­ca­ti­on
Sheng Liang. Addi­son-Wes­ley. ISBN: 0201325772. 1999. 303 Sei­ten
Immer noch ganz ordent­lich zu lesen, obwohl es mehr Bei­spie­le geben könn­te. Zum Glück (ja?) hat bei JNI hat sich wenig ver­än­dert, sodass das Buch wei­ter aktu­ell bleibt. Um JNI zu ler­nen kann man das gan­ze Tuto­ri­al bei Sun aber auch online lesenNovem­ber 2006

Insi­de the Java­OS ope­ra­ting sys­tem
Tom Saul­paugh, Charles Mir­ho. Addi­son-Wes­ley. ISBN 0−201−18393−5. 1999. 184 Sei­ten
Inter­es­sant, was sie dich Men­schen bei Sun so alles aus­den­ken. Spricht da heu­te noch jemand von? Novem­ber 2006

Client/Server Data Access with Java and XML
Dan Chang, Dan Har­key. ISBN 0471245771. 640 Sei­ten. 1998
Ein recht altes Buch, was man nicht mehr lesen muss. Novem­ber 2006

Advan­ced Pro­gramming for the Java 2 Plat­form
Aus­tin Cal­vin, Moni­ca Paw­lan. Addi­son-Wes­ley. ISBN 0201715015. 2000. 381 Sei­ten
Ein Rund­um­schlag über diver­se Java-The­men wie EJB, RMI, JDBC, Swing um eine Auk­ti­ons­platt­form. Buch gibt’s bei Sun online. Kau­fen und lesen lohnt nicht mehr, da es ver­al­tet ist, und es bes­se­re Bücher für die Teil­the­men gibt. Sep­tem­ber 2006.

Java Reflec­tion in Action
Ira R. For­man, Nate For­man. Man­ning Publi­ca­ti­ons. ISBN 1932394184. 2004. 300 Sei­ten
Das eng­li­sche Buch von Man­ning Ver­lag von Ira For­man (Vater) und Nate For­man (Sohn) beschreibt auf 300 Sei­ten und 10 Kapi­teln die Reflec­tion-API und asso­zi­ier­te The­men wie Pro­xy und Quell­code­ge­ne­ra­ti­on. Im ers­ten Kapi­tel ›A few basics‹ gehen die Auto­ren auf die Not­wen­dig­keit für dyna­mi­sche Auf­ru­fe ein, was im zwei­ten Kapi­tel ›Acces­sing fiel­ds reflec­tively‹ gleich für ein Bei­spiel zur XML-Seria­li­sie­rung genutzt wird. Das Kapi­tel nennt auch die Metho­de setAc­ces­si­ble() zum Zugriff auf nicht-sicht­ba­re Eigen­schaf­ten, doch ein Bei­spiel zur Kon­fi­gu­ra­ti­on des Sicher­heits­ma­na­ger mit der Reflect­Per­mis­si­on ›sup­press­Ac­ces­sChecks‹ hät­te den Abschnitt per­fek­tio­niert. Das drit­te Kapi­tel ›Dyna­mic loa­ding and reflec­tive con­struc­tion‹ schließt die Grund­la­gen des Pakets java.lang.reflect mit einer Beschrei­bung zum dyna­mi­schen Klas­sen­la­den und das Ent­wurfs­mus­ter Fabrik ab. Die ers­ten Kapi­tel sind sehr ordent­lich und zeich­nen mit vie­len Details ein gutes Bild der Reflec­tion-API; jedes Kapi­tel im Buch endet mit einem Unter­ka­pi­tel ›Pit­falls‹ und einer Zusam­men­fas­sung. Die nächs­ten drei­ßig Sei­ten des 4. Kapi­tels ›Using Java’s dyna­mic pro­xy‹ ver­an­schau­li­chen die Klas­se java.lang.reflect.Proxy für ein ele­gan­tes Mit­tel zu Umset­zung des Deko­ra­tor-Mus­ters.
Kapi­tel 5 ›Call stack intro­s­pec­tion‹ zeigt abseits der Fra­ge, was Klas­sen kön­nen oder Objek­te haben, wie der Auf­ruf-Stack inter­pre­tiert wer­den kann. Als Anwen­dung nen­nen die Auto­ren Log­ging, Sicher­heits­fra­gen und Kon­troll­fluss (Rekur­si­on erken­nen). Dass Thread seit Java 5 eine Metho­de get­Stack­Trace() besitzt, auch daher kein expli­zi­tes Thro­wa­ble-Objekt mehr nötig ist, erwähnt das Buch nicht, genau­so wenig, dass die Java-Secu­ri­ty 1.2 auf der Basis von Stack-Inspek­ti­on arbei­tet. (Die Web­sei­te http://www.developer.com/java/ent/print.php/610811 gibt einen Ein­blick in die sehr inter­es­san­te Tech­nik.) Das selbst ent­wi­ckel­te Log­ging hat in die­sem Kapi­tel lei­der einen zu hohen Stel­len­wert.
Das 6. Kapi­tel ›Using the class loa­der‹ ver­mu­ten Leser nicht einen Buch über Reflec­tion und daher bie­ten die Auto­ren eine Begrün­dung an: ›sub­clas­sing the class loa­der is a form of reflec­tion‹. Das ist sicher­lich Ansichts­sa­che und genau­so sub­jek­tiv ist die Not­wen­dig­keit für einen Klas­sen­la­der, der sta­ti­sche Attri­bu­te initia­li­siert; auf die Idee wür­de JUnits Test­Case­Class­Loa­der (oder Rel­oa­ding­Test­Sui­teL­oa­der) nie kom­men. Obwohl lib/endorsed zur Spra­che kommt, um Tei­le der Java-API ohne Ände­rung vom Boot­clas­s­path aus­zu­tau­schen, fehlt das offen­sicht­li­che­re lib/extention und auch der Boot­clas­s­path wird nicht erklärt, obwohl das Kapi­tel schon rela­tiv aus­führ­lich auf Klas­sen­la­der ein­geht. Abschnitt 6.4 zeigt, wie ein Klas­sen­la­der aus­se­hen muss, damit Klas­sen ersetzt wer­den kön­nen – ein schö­nen Bei­spiel, das Pro­xy-Pat­tern mit java.lang.reflect.Proxy-Klasse, Klas­sen­la­der und Weak-Refe­ren­ces zusam­men­bringt.
Auf das 7. Kapi­tel ›Reflec­tive code gene­ra­ti­on‹ war ich am meis­ten gespannt. Erwar­tet habe ich die aktu­el­len Biblio­the­ken wie CGLIB, Javassist, ASM, BCEL oder Dyn­class, bekom­men habe ich einen Kom­man­do­zei­len­auf­ruf von javac. (Für Java 6 bekom­men wir hof­fent­lich wie­der eine neue Buch­auf­la­ge, denn eine Com­pi­ler-API ist ange­kün­digt.) Was dann folgt ist ein Pro­gramm, wel­ches Java-Quell­code gene­riert. Sicher­lich eine mit­un­ter nöti­ge Ope­ra­ti­on für MDA, doch dann wür­de ich mir eine Beschrei­bung und Anwen­dung einer Tem­pla­te-Engi­ne wün­schen und kein Java-Quell­code in String-Lite­ra­len, der kon­ka­te­niert in eine tem­po­rä­re Datei geschrie­ben wird. Immer­hin gibt es noch einen kur­zen Bezug zu AOP, doch alles in allem ent­täuscht das Kapi­tel. Ger­ne hät­te ich über einen kom­pi­lier­ten Pro­xy (net.sf.cglib.proxy.Proxy) gele­sen oder über den Bean-Eigen­schaf­ten-Kopie­rer net.sf.cglib.beans.BeanCopier, der nicht wie die Apa­che Com­mons Bea­nU­tils bei BeanUtils.copyProperties() über Reflec­tion geht – auch zu die­ser sehr schö­nen Reflec­tion-Anwen­dung. Gro­ße Real-Life Appli­ka­tio­nen wie JBoss oder der OR-Map­per Hiber­na­te zei­gen einen unver­blüm­ten Ein­satz der dyna­mi­schen Byte­code­ge­ne­ra­ti­on, was die Auto­ren zusam­men mit den Tools CGLIB, Javassist, BCEL in einer beschei­de­nen Fuß­no­te auf der vor­letz­ten Sei­te des Kapi­tels aber immer­hin erwäh­nen: ›As evi­dence, we offer the fact that the buil­ders of power­ful tools […] are using cglib […]‹. Die knap­pe Dar­stel­lung reicht in einem Buch über Reflec­tion nicht aus. Auch hilft der Ver­weis auf ande­re Büchern wie ›Code Gene­ra­ti­on in Action‹ – das Javassist, cglib, BCEL noch nicht mal erwähnt – und ›Gene­ra­ti­ve Pro­gramming: Methods, Tools, and App­li­ca­ti­ons‹ nicht aus. Dass man Quell­code für ›Design pat­terns‹ auch gene­rie­ren kann zeigt das 8. Kapi­tel. Reflec­tion liest Ele­men­te wie Kon­struk­to­ren aus und gene­riert Sin­gle­ton, Deko­ra­tor und Pro­xy; die Auto­ren nen­nen das ›class-to-class trans­for­ma­ti­on‹. Beim Sin­gle­ton fin­det sich ein klei­ner Feh­ler im Text, dass die Auto­ren anneh­men, dass bei clo­ne() nie gilt: ref == ref.clone(). Das ist falsch, denn auch die API-Doku­men­ta­ti­on von Sun nennt eine Anwen­dung bei immu­ta­ble-Objek­ten – so lie­fern bei­spiels­wei­se die Wrap­per-Objek­te immer die this-Refe­renz. Eine Bei­spiel­an­wen­dung gene­riert Quell­code für ein Sin­gle­ton, obwohl nicht ganz klar wird, was das Bei­spiel eigent­lich zei­gen soll. Der fol­gen­de gene­rier­te Deko­ra­tor tes­tet Inva­ri­an­ten, lei­der fehlt ein Bezug zu moder­nen AOP-Frame­works, die die­se Auf­ga­be stan­dard­mä­ßig mit simp­len Inter­cep­to­ren lösen. (JBoss AOP ver­wen­det für Frame­work an vie­len Stel­len Stan­dard-Reflec­tion.)
Kapi­tel 9 ›Eva­lua­ting per­for­mance‹ stellt Micro-Bench­marks vor. Ein Test­pro­gramm misst a) die Lauf­zeit für direk­te Metho­den­auf­ru­fe, b) Metho­den­auf­ru­fe durch Pro­xy-Objek­te, die eine Metho­de direkt auf­ru­fen, und c) Pro­xy-Objek­te, die über Reflec­tion eine Metho­de auf­ru­fen. Die Auto­ren kom­men für Auf­ru­fe ohne Argu­men­te auf fol­gen­de Zah­len: Der direkt ansprin­gen­de Pro­xy benö­tigt etwas mehr als dop­pelt so viel Zeit wie ein direk­ter Metho­den­auf­ruf. Am Teu­ers­ten ist der Auf­ruf über Reflec­tion: 331 Mal teu­rer als ein direk­ter Auf­ruf. Die Tests wur­den unter Win­dows 2000 mit Java 1.4.1 durch­ge­führt. Obwohl der Bench­mark auf den ers­ten Blick einen Geschwin­dig­keits­ver­lust attes­tiert, rela­ti­vie­ren die Auto­ren im nach­fol­gen­den Abschnitt die Bedeu­tung der Zah­len und brin­gen eine inter­es­san­te Anwen­dung von Amdahls Gesetz. Das Kapi­tel bremst Ent­wick­ler, die immer auf Grund von Micro-Bench­marks ihr Design ändern wol­len.
Das 10 Kapi­tel ›Reflec­ting on the future‹ stellt den Lesern kurz Reflec­tion bei ande­ren Spra­chen vor: C#, Python, Small­talk, Ruby, Perl. Auf etwa einer Sei­te schrei­ben die Formans über Aspekt­ori­en­tier­te Pro­gram­mie­rung, ohne jedoch Reflec­tion und AOP in einen gro­ßen Bezug zu stel­len. Wei­ter­hin beschreibt das zehn­te Kapi­tel Eigen­schaf­ten von Java 5, auf das eigent­lich das Buch hät­te bau­en sol­len. Zwar erklärt das Kapi­tel Anno­ta­tio­nen gut, doch scha­de, dass das Anno­ta­ti­on Pro­ces­sing Tool (apt) nicht genannt wird. Hier müs­sen die Auto­ren für die nächs­te Auf­la­ge nach­bes­sern. Drei Anhän­ge schlie­ßen das Buch. Anhang A ›A Reflec­tion and meta­ob­ject pro­to­cols‹ ist der phi­lo­so­phi­sche Teil. Es geht um Meta-Pro­gram­me, Meta-Level und Base-Level, um das Modell von Fried­man und Wand, um das Meta-Objekt Pro­to­koll. Anhang B geht das Pro­blem mit waitFor() bei extern gestar­te­ten Pro­gram­men nach und Anhang C wie­der­holt zen­tra­le Sym­bo­le in UML-Dia­gram­men. Ein Glos­sar – wobei die meis­ten Begrif­fe aus dem Anhang B stam­men – und eine Lite­ra­tur­an­ga­be mit fast 100 Quel­len been­den das Buch.
Ins­ge­samt bie­tet das Buch einen schö­nen Ein­stieg in das Reflec­tion-Model von Java und stellt durch den Anhang auch wis­sen­schaft­lich ambi­tio­nier­te Leser zufrie­den. Für Ent­wick­ler, die sich erst­ma­lig mit Reflec­tion beschäf­ti­gen, brin­gen die ers­ten Kapi­tel den meis­ten Gewinn. Bei eini­gen Kapi­teln (Code-Gene­ra­ti­on) fehlt die Tie­fe, die Ent­wick­ler erhof­fen. Zumin­dest drei Kapi­tel sind im Inter­net frei zugäng­lich (Kapi­tel 1 und 5 unter http://www.manning.com/forman/, Kapi­tel 4 unter http://www.webreference.com/internet/reflection/) und erlau­ben einen ers­ten Ein­blick. Da das Buch im Okto­ber 2004 auf den Markt kam, Java 5 aber erst Ende Sep­tem­ber, lässt sich die Ent­schei­dung für Java 1.4 ver­ste­hen. Die Auto­ren beschrei­ben zwar im zehn­ten Kapi­tel die Neue­run­gen wie Auto-Boxing, Gene­rics und Varia­ble Argu­men­te, doch in der nächs­ten Auf­la­ge des Buches ist eine kon­se­quen­te Nut­zung in den Bei­spie­len und API-Beschrei­bun­gen wün­schens­wert. Die Reflec­tion-API nutzt Java 5 Eigen­schaf­ten reich­hal­tig:

Point p = new Point();
Method m = p.getClass().getMethod( "setLocation", int.class, int.class );
m.invoke( p, 1, 2 );
System.out.println( p );

Class ist gene­ri­fi­ziert und Funk­tio­nen wie get­Me­thod() und invo­ke() ermög­li­chen varia­ble Argu­ment­lis­ten. August 2005

Tricks of the Java Pro­gramming Gurus
Glenn L. Van­der­burg und wei­te­re
Einer der ers­ten ›Tipps und Tricks‹-Bücher mit 35 Kapi­teln. Vie­le Kapi­tel wie­der­ho­len ein­fach nur Stan­dard-Wis­sen, und nur bei weni­gen Abschnit­ten fin­det man Tricks, die man in einem ›Guru‹-Buch eigent­lich erwar­ten dürf­te. Kapi­tel 1 geht auf Fra­ge ein: Wie kom­mu­ni­zie­ren App­lets? (Con­text, sta­ti­sche Varia­blen). Kapi­tel 2: Wie funk­tio­niert das Laden mit dem Media­Tra­cker? (Der Media­Tra­cker infor­miert über den Sta­tus, was ImageIO nicht tut). Dass der Media­Tra­cker aller­dings mehr gewor­den ist als ein Bil­der­la­der hat sich nicht bestä­tigt. Im Kapi­tel 3 fol­gen Netz­werk­the­men: URLURLConnection und Über­mitt­lung via POST, Socket. Das 4 Kapi­tel han­delt über Audio und die Klas­se AudioClip. Für heu­te Appli­ka­tio­nen unin­ter­es­sant mit der Aktua­li­sie­rung in Java 1.2. Auch das nächs­te Kapi­tel ist nicht Tipp-Ver­däch­tig: IO-Streams und RandomAccessFile. Im anschlie­ßen­den 5. Kapi­tel wer­den Threads und die ThreadGroup vor­ge­stellt; auch ein Stan­dard für Stan­dard-Java-Ein­füh­rungs­bü­cher. Gut ist jedoch ein Bezug auf ein wenig Inter­na, wie der Ver­knüp­fung von Thread und Thre­ad­Group und wer da einen Ver­weis auf wen hält sowie Erklä­rung der Green-Thread-Imple­men­tie­rung in früh­ren Java-Ver­sio­nen. Das 7. Kapi­tel erwei­tert dann Threads um die The­men Neben­läu­fig­keit und Syn­chro­ni­sa­ti­on — alles Stan­dard-Buchthe­men. Sep­tem­ber 2005

Teach Yours­elf Inter­net Game Pro­gramming With Java in 21 Days
Micha­el Mor­r­i­son. Sams.net. 1996. ISBN 1575211483. 416 Sei­ten
Ok. Das Buch ist von 1996 und man muss sich mit Java 1 begnü­gen. Das ist aber nicht mei­ne Kri­tik am Buch, son­dern dass es Java-Stan­dard­wis­sen in einem Buch ver­brei­tet, was sich mit schwer­punkt­mä­ßig mit Spie­le-Pro­gram­mie­rung aus­ein­an­der­set­zen möch­te. Das schafft der Autor nicht, denn er reißt ledig­lich ein paar Tei­le an, wie Spri­t­es und belässt übri­ges oft auf sehr nied­ri­gem Niveau; was ist GIF, was ist AI.Sep­tem­ber 2005

Data Struc­tures and Pro­gramming
Liwu Li. Sprin­ger-Ver­lag Ber­lin Hei­del­berg. ISBN 354063763X. 1998. 483 Sei­ten
Lei­der nur ein Buch, was in Java ein­führt, aber wenig auf die Daten­struk­tu­ren ein­geht. Das Buch asso­zi­iert für mich im Wesent­li­chen Daten­struk­tu­ren, aber das ist nur ein klei­ne­rer Teil. Sonst wie­der eine Java-Ein­füh­rung. Die Daten­struk­tu­ren sind auch nicht umwer­fend, sonst nur die ›Stan­dard-Daten­struk­tu­ren‹ ziem­lich schwach beschrie­ben. Lohnt sich in mei­nen Augen nicht. Novem­ber 2003

Open Java. Von den Grund­la­gen zu den Anwen­dun­gen
Ste­phan Fischer, Abdul­mo­ta­l­eb El-Sad­dik. Sprin­ger-Ver­lag. 1999
Die ers­te Sei­te, die ich in die­sem Buch auf­schlug, ent­hielt den Satz ›Tech­ni­ken, wie die auto­ma­ti­sche Typ­an­pas­sung sind in Java aus­drück­lich ver­bo­ten.‹ Nach die­sem Satz dann der Schock und die Fra­ge, wie es auf den ande­ren 700 Sei­ten wei­ter gehen soll. Im Prin­zip in Ord­nung. Eini­ge Aus­sa­gen ver­blüf­fen mich aber doch: ›Das Lauf­zeit­sys­tem […] geht des­halb sehr spar­sam mit den zur Ver­fü­gung ste­hen­den Res­sour­cen um‹. Das zum The­ma ›Schnel­lig­keit‹. Na ja. Auch Objekt­va­ria­blen als ›loka­le Varia­blen‹ und sta­ti­sche Varia­blen als ›glo­ba­le Varia­blen‹ zu dekla­rie­ren irri­tiert mich. Call-by-Refe­rence, Klas­sen­na­me 3DPunkt geht doch gar nicht, was soll java.lang.package für ein Paket sein? (es gibt recht neu eine Klas­se java.lang.Package, aber die mein­te der Autor sicher­lich nicht), ›4 ins­tan­ce­of String‹ kom­pi­liert gar nicht erst (seit Java 5 kann man neu dar­über dis­ku­tie­ren) und kann nicht fal­se erge­ben. Didak­tisch Vec­tor und Hash­t­a­ble vor Schlei­fen? Hat eine Metho­de einen Typ? Ok, einen Rück­ga­be­typ, aber Typ allei­ne? Wie imple­men­tie­ren Java-Ver­sio­nen vor 1.2 die Schnitt­stel­le Array? Uff. Eine Klas­se, die eine Exce­ti­on wirft. Das kann doch nicht sein (Sei­te 139). stop/resume/suspend war schon seit 1.2 auf einer Thre­ad­Group depre­ca­ted. Dann noch so dies oder das. Doch zum Guten. Ins­be­son­de­re im hin­te­ren Bereich hat das Buch sei­ne Stär­ken. Ordent­lich beschreibt es Java­Be­ans, JDBC, RMI, CORBA. Das sind aller­dings die 66,95 Euro nicht wert (die jeden­falls Ama­zon ver­langt). Okto­ber 2002

Java Unleas­hed 1.1
Micha­el Mor­r­i­son. Sams. ISBN 1575211971. 1996. 1164 Sei­ten
Natür­lich maß­los ver­al­tet, aber noch mal zum drü­ber­blät­tern ganz nett. Inter­es­sant, was damals schon in den Büchern stand, Java­OS. Hört man heu­te gar nichts mehr von. Mai 2002

Spre­chen Sie Java? Eine Ein­füh­rung in das sys­te­ma­ti­sche Pro­gram­mie­ren
Hans­pe­ter Mös­sen­böck. dpunkt-Ver­lag. ISBN 3898641171. 2001. 299 Sei­ten
Typi­sches Uni-Buch. Kei­ner­lei Biblio­the­ken wer­den ein­ge­führt. Daher für den typi­schen Indus­trie­pro­gram­mie­rer unbrauch­bar. Eini­ge Feh­ler in den Bei­spie­len. Preis: 54,00 DMNovem­ber 2001

Java by Dis­sec­tion: The Essen­ti­als of Java Pro­gramming
Ira Pohl, Char­lie McDo­well. Addi­son-Wes­ley. ISBN 0201612488. Okto­ber 1999. 656 Sei­ten
Durch­schnitt­li­ches Java­buch. Nicht unbe­dingt so toll. Novem­ber 2001

Pro­gram­mie­ren mit Java. Das Lehr­buch zum siche­ren Umgang mit Objek­ten
Andre­as Soly­mo­si, Ilse Schmie­de­cke. View­eg Ver­lags­ge­sell­schaft. ISBN 3528256974. 2001
Recht güns­ti­ges (57,99 DM) Java-Buch zu einer Vor­le­sung. Etwas didak­tisch merk­wür­di­ger Auf­bau. Erst auf Sei­te 200 Steu­er­struk­tu­ren; sehr frag­wür­dig. Sep­tem­ber 2001

Java — platt­form­un­ab­hän­gig pro­gram­mie­ren
O’Niel Ann­and Valen­tin Som. bhv-Ver­lag. ISBN 3−89360−302−6. 1997, 208 Sei­ten
Oh Gott. Das darf nicht sein! Das schlech­tes­te Java-Buch in die­sem Quar­tal. Küm­mert sich nur um eine lasche Ein­füh­rung und dann kommt nur noch etwas AWT. Wun­dert mich über­haupt, dass der Autor das Grid­Bag­Lay­out fast ver­stan­den hat. Sonst sei­ten­wei­se pein­li­che Feh­ler, die mich zur Kor­rek­tur zwan­gen. Eini­ge Bei­spie­le: ›Der ers­te Buch­sta­be eines Bezeich­ners kann […] aber kein Umlaut sein.‹ (Unsinn), ›[…] zuge­grif­fen wer­den, mit this auf die aktu­el­le Klas­se‹ (Objekt, nicht Klas­se ), ›Zur Umwand­lung eines Typs in einen ande­ren ist eine aus­drück­li­che Auf­for­de­rung an den Com­pi­ler not­wen­dig […]‹ (Quatsch, nur bei expli­zi­ten Typ­an­pas­sun­gen), ›Wird eine Metho­de nicht son­dert mit einem […] Modi­fi­zie­rer gekenn­zeich­net, dann gilt sie als pri­va­te […]‹ (Natür­lich nicht, sie ist paket­sicht­bar) und so wei­ter. Mein Lieb­ling ist: ›Nach dem Schlüs­sel­wort syn­chro­ni­zed kann eine Varia­ble ange­ge­ben wer­den, die wäh­rend des fol­gen­den Blo­ckes nicht von ande­ren Threads aus zugäng­lich ist.‹ Juli 2001

Ein­füh­rung in die objekt­ori­en­tier­te Pro­gram­mie­rung mit Java
Ernst-Erich Dober­kat, Ste­fan Diß­mann, Olden­bourg. ISBN 3486247867. 2000. 315 Sei­ten
Für Stu­den­ten mit Erfah­rung in ande­ren Pro­gram­mier­spra­chen ganz nett. Hält sich lei­der nicht an die Java-Namens­kon­ven­ti­on. Sonst ein paar net­te Algo­rith­men erklärt. Juli 2001

Java in der Anwen­dungs­ent­wick­lung. Objekt­ori­en­tie­rung, Ver­tei­lung, Daten­ban­ken
Gerald Ehmay­er, Sieg­fried Reich. dpunkt-Ver­lag. ISBN 3920993845. X Sei­ten
Altes Buch mit völ­lig unpas­sen­der Titel­be­schrei­bung. Unprä­zi­se und unge­nau. Febru­ar 2001

Java
Wal­ter Dobe­renz. Han­ser-Pro­gram­mier-Pra­xis. ISBN 3−446−18854−1. 1996. 494 Sei­ten
Noch so‚n schlech­tes Java­buch, über das man eigent­lich kein Wort ver­lie­ren brauch. Dem Zeit­punkt nach zu urtei­len eines der frü­hen Buch auf dem deut­schen Markt. Dass es schlam­pig geschrie­ben ist, merkt man z.B. an vie­len groß geschrie­be­nen Metho­den­na­men in Tabel­len (eige­ne Lieb­lings­ei­gen­schaft von MS-Word). Die let­zen Sei­ten sind ein Qui­cky durch ein paar FAQs, Imple­men­tie­rungs­schnipp­sel hin­ge­schmiert, ohne gro­ße Erklä­rung. OOP kommt dann auch erst nach allem ande­ren Java-Typi­schen. Daher: unbrauch­bar.  Janu­ar 2001

Java Gent­ly
Judy M. Bishop. Addi­son-Wes­ley. ISBN 0−201−342979. 1998. 508 Sei­ten
Hach, ich traue mich gar nicht ein schlech­tes Wort über die­ses Buch zu ver­lie­ren, da doch vie­le Didak­ti­ker mit dem Buch so glück­lich sind. An der Uni Pader­born wer­den die Ein­füh­rungs­ver­an­stal­tun­gen mit die­sem Buch gemacht und Herr Kas­tens hat sogar eine deut­sche Über­set­zung initi­iert. Ehr­lich gesagt fin­de ich die­se Buch zwar nicht didak­tisch grot­ten­schlecht aber zu einem gut kann ich mich nicht durch­rin­gen. Vor mir liegt die zwei­te Auf­la­ge von 1998,die das JDK 1.1 als Unter­la­ge ver­wen­det. Begin­nen wir mit der Methodik/Didaktik: <sub­jek­tiv on>Die Rei­hen­fol­ge der Prä­sen­ta­tio­nen der Inhal­te fin­de ich sehr frag­wür­dig: Grund­la­gen OOP, Datei­ein­ga­be/-aus­ga­be, if, Excep­ti­ons, while/do, switch, Arrays, For­ma­tie­rungs­klas­sen, OOP, inne­re Klas­sen, Abs­trak­ti­on und Ver­er­bung, GUI, Ereig­nis­se, App­lets, Threads, Netz­wer­ke, Algo­rith­men und DS. Bevor die ers­te Schlei­fe oder Fall­an­wei­sung kommt wird der Leser mit Objek­ten, Kon­struk­to­ren, Kon­stan­ten behel­ligt. So ist es immer ein Misch­masch von Kon­zep­ten aber ich erken­ne kei­nen roten Faden. Das heißt aber noch lan­ge nicht, dass das alles nicht zusam­men­passt. Das schon. Es ist alles schön auf­ein­an­der abge­stimmt. Nur glau­be ich nicht, dass der Leser dies mit sich machen lässt. Zur Didak­tik: Was sie schreibt ist gut, mit schö­nen Bei­spie­len und Auf­ga­ben. Wenn es anders sor­tiert wäre ich durch­aus glück­lich damit. <sub­jek­tiv off> Wor­an aber nichts zu zwei­feln gibt sind die unsäg­li­chen Inkon­sis­ten­ten in der zwei­ten Auf­la­ge. Pein­lich. Sie betref­fen zum Bei­spiel die Bezeich­ner­na­men, mal sind Varia­blen klein/groß, Kon­stan­ten immer klein geschrie­ben, in den klei­nen Info-Blö­cken mal Schlüs­sel­wör­ter groß, mal in Fett­druck. Mal Leer­zei­chen hinter/vor Metho­den, mal nicht. Als Buch, wel­ches vor­gibt Metho­dik zu leh­ren, darf dies nicht pas­sie­ren. Dann noch eini­ge Unge­nau­ig­kei­ten in den Biblio­the­ken. Unter ande­rem liegt das an der Ver­si­on 1.1. Es gibt auch eine Float.parseFloat() Metho­de. Schlimm auch fol­gen­de Zei­le:

URL info = new info( "file:/u/...usw. ...Museum.java" );

Dar­un­ter noch mal ein Buf­fe­red­Re­ader Feh­ler. Damit genug gesagt. Jetzt geht’s zurück ins Bibo-Regal. Die zwei­te Auf­la­ge habe ich noch nicht begut­ach­tet. Juli 2k

Die Java2 Fibel
Ralf Künel. Addi­son-Wel­sey. ISBN 3−8273−1410−0. 1999. 442 Sei­ten
Vor mir liegt die drit­te Auf­la­ge des Buches, frisch über­ar­bei­tet mit den Fea­tures vom JDK 1.2. Lei­der ist das Buch nicht qua­li­ta­tiv bes­ser gewor­den, son­dern es beschreibt nur eini­ge neue Eigen­schaf­ten. Der Ein­stieg in die Spra­che ist ganz ordent­lich (ers­ten 100 Sei­ten), doch dann geht es etwas schnell. Die ein­ge­streu­ten Lis­tings irri­tie­ren mich. Kei­ne ver­nünf­ti­ge Ein­füh­rung in das AWT und Zei­chen­ope­ra­tio­nen. Didak­tisch nicht toll. Das Buch wür­de ich mir auf kei­nen Fall kau­fen. Wenn man es als Fort­ge­schrit­te­ner ein­mal in der Hand hat, kann man von 4 Sei­ten über Schwa­chen Refe­ren­zen pro­fi­tie­ren, sonst Fin­ger davon.April 2k

Java 1.2: Java-Tuto­ri­al Pro­gram­mie­rung von Appli­ka­tio­nen, die Schnitt­stel­le zu C und C++, Klas­sen­bi­blio­the­ken, aus­führ­li­che Refe­renz
Ralf Stey­er. M&T Ver­lag
Nein, die­ses Buch steht hier bestimmt nicht weil ich es toll fand, son­dern weil es der­ma­ßen schlecht ist, dass ich die Welt vor die­sem Buch war­nen muss. (Wer nun aller­dings denkt, ich ste­he mit mei­ner Mei­nung allei­ne, der soll­te mal bei Ama­zon unter den Rezen­sio­nen durch­le­sen. Wobei ich glau­be, die guten Kri­ti­ken hat er von sei­nen Freun­den). Das Buch ist so schlecht, dass man auf jeder Sei­te den Rot­stift anset­zen muss. Wie dies über­haupt erst gedruckt wer­den konn­te ist ein Wun­der. Und hier sieht man mal wie­der, wie der M&T Ver­lag Kas­se machen will. Auf dem Buch­rü­cken steht voll­mun­dig: RMI. Ich fall‘ um; eine Sei­te. Ser­v­lets — 4 Sei­ten. JDBC 12 Sei­ten. Und all dies seht vor­ne drauf und lockt uns an. Nicht bes­ser sieht es mit der nati­ven Anbin­dung aus, eine Ankün­di­gung, die schon der Titel des Buches ver­rät. Hier wer­den wir mit 14 Sei­ten nach Hau­se geschickt. Na ja, und über den Rest brau­che ich wohl nicht vie­le Wor­te ver­lie­ren. 250 Sei­ten Bla Bla, bis es mal zur Sprach­be­schrei­bung kommt. Gigan­ti­sche drei Sei­ten über Swing, obwohl das Buch von 1998 ist, usw. usw. Sep­tem­ber 1999