Allgemeine Java-Bücher, Einführungen

Java 1.5 Tiger: A Developer’s Notebook
David Flanagan, Brett McLaughlin. O’Reilly. ISBN 0-596-00738-8. Juni 2004. 200 Seiten
Realtiv schwaches Java 1.5 Buch, welches wirklich nur die bekannten Features aufzeigt. Schon die tutego-Webseite zu den Java 1.5 Änderungen gibt mehr her als dieses Buch. 2008

Java als erste Programmiersprache – vom Einsteiger zum Profi
Joachim Goll, Cornelia Weiß, Frank Müller. B.G. Teubner Verlag. ISBN 978-3519226420. 880 Seiten
Erscheint mir als akzeptables Uni-Buch. Viele gute Abbildungen. Objektorientierung „fühlt“ man aber nicht nicht wirklich. Klar, wird erklärt, was Vererbung und Polymorphie ist, aber das OOP-Beispiel sollte schon durchgängig sein. (Und dann wieder ein dummes Beispiel, dass ein Student eine Person ist…) Eine neue Auflage ist verfügbar. 2008

Hardcore Java
Robert Simmons. O’Reilly. ISBN 0-596-00568-7. März 2004. 344 Seiten
Warum tut mir O’Reilly das an? Ich setze es ohne Bedenken auf Platz 1 in der Liste der Java-Bücher, die einen völlig verfehlten Titel tragen. Im Vorwort wird noch groß verkündet: „We’re talking about difficult but extremely powerful and useful programming techniques like reflection, advanced data modeling, advanced GUI design, and advanced aspects of JDO, EJB and XML-based web clients. This unique book reveals the true wizardry behind the complex and often-mysterious Java environment.“ und dann kommt nur Anfängerstoff und nix von JDO, EJB oder XML. Dafür umso mehr Kindergartenthemen: Jede Klasse ist von java.lang.Object abgeleitet, ein „if“ verträgt auch komplexe Anfragen mit ZWEI Bedingungen oder dass es einen ?-Operator gibt. Echt Hardcore! Des Weiteren deklariert Felder in umständlicher Syntax int[] AN_ARRAY = new int[] {1, 2, 3, 6, 9, 18, 36}; statt einfach nur int[] AN_ARRAY = {1, 2, 3, 6, 9, 18, 36}; Und schließlich 30 Seiten Auseinandersetzung von final. Die Namen der Color-Konstanten sind klein statt groß (gibt es „erst“ seit Java 1.4) geschrieben, und warum der Autor in dem Calendar-Beispiel ausdrücklich nach GMT fragt, ist ebenfalls sonderbar, denn für das Beispiel spielt das überhaupt keine Rolle:

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

Im nächsten Kapitel über immutable kommt natürlich der Hinweis auf String (immutable) und Point, Date, StringBuffer (nicht immutable), aber wertvolle Hinweise, etwa das immutable-Typen die Entwicklung von multitheaded-Anwendungen massiv erleichtern und immutable Objekte gut in einen Pool passen (wie einige Wrapper-Objekte in Java 5) werden unter den Teppich gekehrt. Immerhin erwähnt er die Unmodified-Wrapper. Weiter zum nächsten Hardcore-Thema, der Collection-API. Mr. Simmons schreibt: „…code is an example of a good interface-based technique:“

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

Der Objekttyp von someSet sollte wohl Set statt HashSet sein. Und warum ist in dem Beispiel die Methode gerade protected? Und someSet paketsichtbar? Da steckt vermutlich Hardcore Java Design-Erfahrung im Code. Na ja, dann hakt das Kapitel noch mal eben alle Hardcode-Collection-Klassen ab. Dass Robert fail-fast von Iteratoren erklärt, ist super, aber dann der nächste Rückschlag bei set.add(new String("p->" + element)). Was soll denn das heißen? Das nächste Kapitel heißt Exception-Handling (in welchem Java-Einführungsbuch steht das bitte schön nicht?) und der Hinweis, dass finally eine gute Stelle ist, um Datenbankverbindungen zu schließen. Das folgende Kapitel ist noch viel härter. Es geht um innere Klassen. Jetzt ist es an der Zeit, sich jeden Satz ganz genau anzuschauen und sich hoch zu konzentrieren. Radio aus, Fernseher aus, Computer aus. Weiter zum nächsten Hammerthema – Konstanten und Internationalisierung. Dass Robert auch Klammern kennt, zeigt er in Anweisungen wie dieser:

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

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. (Aber DDD war damals wirlich noch was neues.) 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. Mai 2008

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

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

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

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 (wiehttp://mina.apache.org/) 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 Anweisungorg.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. August 2007

Bitter Java. The lessons taught by server-side Java antipatterns  
Bruce A. Tate. Manning. ISBN 193011043X. 2002. 368 Seiten
Das Buch habe ich schon relativ lange und vor ein paar Jahren warf ich schon einmal einen Blick darauf. Ich hatte es wieder zur Seite gelegt, da es mich damals nicht so angemacht hat und die einführenden Geschichten mich langweilten. Da das Buch jetzt ›raus‹ sollte, nahm ich es mir noch etwas genauer vor. Kurz gesagt: Es langweilt mich immer noch. Im meinen Augen ist es ein Buch mit sehr wenig Inhalt gesegnet und dazu noch mit Listings, die unglaublich flau sind. Didaktisch bin ich kein Freund der Strategie erst-mal-alles-falsch-zeigen-und-dann-100-Seiten-weiter-korrigieren. Das Buch basiert auf der Idee. Und so wundert man sich als Leser kapitelweise, warum denn zum Beispiel Datenbankverbindungen nicht in einem finally geschlossen werden; das klärt erst das Kapitel 7.3.2 auf. Ebenfalls Datenbankenverbindungen: Sie werden immer wieder auf- und abgebaut, obwohl das die größte Performance gibt. Schade, dass das erst später in Kapitel 7.2.3 erklärt wird. Dann wäre aber eine Nennung einiger Open-Source Connection-Pools nicht falsch. Quer durch viele Listings – nicht alle – finden sich Datenstrukturen wie Vector oder Hashtable, in einigen anderen wiederum die Type der Collection-API. Überhaupt entwickelt Bruce vieles selbst, etwas das Cache-Management mit einer Hashtable. Warum hier keine Open-Source Lösungen genannt werden, verstehe ich nicht. Das gleiche auch bei einem selbst entwickelten Controller bei JSPs. Dass JSP wenig/kein Java-Quellcode enthalten sollte, müsse heute wirklich jedem Entwickler klar sein; aber seine Lösung, die Java EE Pattern selbst zu implementieren finde ich keine gute Idee. Stilistisch gibt es weitere Schwächen, extrem viel im Bereich Exception-Handling. Hier weiß ich überhaupt nicht, was Bruce sich dabei gedacht hat. Einige Beispiele: Warum wird zum Öffnen einer Datenbankverbindung mit vorangehendemClass.forName() ein Throwable gefangen? Warum werden gleich zwei RuntimeException nach oben geleitet wie in getAuthor und später nach mal in getNumber():

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

Dann werden Typen aus dem java.lang-Paket, wie im Kapitel 6.3.1 mit catch(java.lang.Throwable) voll qualifiziert; und immer wieder wird Throwable aufgefangen. Und ich kann auch nicht sehen, warum es beim Erzeugen eines Punktes und Aufrufes dreier Setter zu einer Ausnahme kommen kann, die man abfängt. Danach noch mal das gleiche mit einem TextField. Und warum AWT und nicht Swing?

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

Oder auch dieses Exception-Konstukt:

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

Weitere Beispiele lassen an den Korrekturlesern zweifeln. Der Schleifenzähler ist i, aber im Rumpf wird er mit _i genutzt. Dann eine Zähler-Klasse:

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

Ganz davon abgesehen, dass man Klassen großschreiben sollte, kann man (jedenfalls nicht bist Java 5) mit Wrapper-Objekte nicht rechnen und auch nicht mit 0 initialisieren. Und warum werden Objektvariablen mit null initialisiert, wie bei private D d_ = null;? Einen Knüller fand ich händisch konkatenierte SQL-Anweisungen, statt gleich PreparedStatements zu verwenden: wie "SELECT subject, author, board, number from posts where board='" + getBoard() + "' and parent=0" oder noch „besser“

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

Dann werden erst mal wieder alle EJB-Basics rausgekramt: Es muss ein Remote-Interface geben, dann ein Home, Deployment-Deskriptor, usw. Was es hier zu Verbessern gibt, ist lächerlich: Alle deklarierten Entity-Beans sind remote und die Verbesserung – welch Wunder – eine Fassade. Aber das dies keine gute Idee ist, müsste nun eigentlich jedem EJB-Entwickler gekannt sein – und unter EJB 3 glücklicherweise nicht mehr möglich. (Merkwürdig ist aber schon, dass eine Web-Anwendung remote auf EJBs zugreift, aber lassen wir uns auf diese Annahme ein.) Und vernichtende Aussagen über CMP gefallen mir so pauschal nicht: „For EJBs, the Golden Hammer is usually the entity bean with container managed persistence. This is also the EJB classification with the most overhead. If every object in our model is a container-managed entity bean, we might want to hunker down behind the desk to prepare for the deluge of customer complaints about performance.“ In den JSPs gibt es for-Schleifen statt Iterator-Tags. Der Rest sind dann ein paar Coding-Conventions; nur schreibt man üblicherweise keinen Doppelpunkt hinter das Java-Doc-Tag @author. Dann schnell noch Wiederholungen der Java-Sichtbarkeit. Wer weiß als Entwickler nicht, was public, protected, … bedeutet? Performance-Tipps wie: Halte in Schleifen die redundanten Berechnungen raus sind an sich gut, aber das Beispiel for ( int i=0; i < collection.size(); i++) ist relativ wertlos – die Methodesize() kann HotSpot leicht inline setzen. Da gibt es dringendere Probleme. Die Stil-Regel ›Typically, import statements should import java.util.* rather than java.util.Vector‹ to make maintainability simpler.‹ gefallen mir überhaupt nicht. Die Anzahl der Import ist sehr wichtig, um etwas über die Anzahl Abhängigkeiten herauszufinden – sie sollten nicht zu groß sein. Wenn, dann ist das ein Indiz dafür, dass der Typ ›zu viel macht‹. Eine Interessante Idee ist, Fehler mit 8 Einheiten einzurücken, den Rest aber mit 4. Das muss ich mir optisch einmal anschauen. In der Summe: Die Infos bekommt man besser, etwa in einem Pattern-Buch, Buch über Performance oder Stil-Buch. August 2007

Java Secrets
Elliotte Rusty Harold. IDG Books. ISBN 0764580078. 1997
Die Secrets sind zum Teil wirkliche Secrets, aber nicht, weil die ersten Kapitel über „Primitive Data Types“, „Classes, Strings, and Arrays“, „Applets“, „The Java Virtual Machine“ handeln, sondern wegen dem Kapitel „The Sun Classes“. Harold stellt viele der internen sun-Klassen 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 einzig merkwürdige war die Aussage „JDBC stands for ‚Java DataBase Connectivity'“. Mai 2007

Java Software Solutions: Foundations of Program Design
John Lewis, William Loftus. Addison-Wesley. ISBN 0201571641. 1997. 857 Seiten 
Meine erste Auflage beschreibt erst Java 1.1, aber wenn ich denke, dass es das Buch auch in einer Java 5 Auflage gibt, kann man das Buch für Studenten empfehlen. Zweifarbig gedruckt. Zum Teil didaktisch mehrwürdige Reihenfolgen, aber das tut nicht unbedingt einen Abbruch. John Lewis hat unter http://duke.csc.villanova.edu/jss1/ eine Webseite für die 4. Auflage, auf der er Dinge wie Folien abgelegt hat. Mai 2007

Java Standard Libraries. Java 2 Collections Framwork und Generic Collection Library for Java
Markus Gumbel, Marcus Vetter, Carlos Cardenas. Addison-Wesley. ISBN 3827316359. 518 Seiten
Recht schönes Buch. Zwar auf dem Stand von Java 1.3, sodass die neuen Datenstrukturen insbesondere aus Java 5 und Generics fehlen und man sich die Generic Collection Library for Java (JGL) heute schenken kann, aber dennoch ein schöner Einsteig. Sehr ausführlich ist der Vergleich mit der C++ STL. April 2007.

Java Language Reference
Mark Grand. O’Reilly. ISBN 1-56592-204-2. 448 Seiten
Alternative Dokumentation zur Java Sprachbeschreibung mit netten Diagrammen für die Sprachsyntax (railroad diagrams). Es gab ein Update von Java 1.0 auf Java 1.1 (für die inneren Klassen), aber danach gab es keine Buch-Updates mehr. Februar 2007

Java 6 Plattform Revealed
John Zukowski. APress. ISBN 1590596609. 220 Seiten
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 CookieHandlerCookieManager & 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. Januar 2007

Java. Die Spezifikation der virtuellen Maschine
Tim Lindholm, Frank Yellin. Addison-Wesley. 1. Auflage. ISBN 3-8273-1045-8. 1987. 450 Seiten
Das Buch ist sicherlich kein packender Thriller, doch glaube ich, jeder sollte die Spezifikation der JVM einmal gelesen haben. (Man muss dazu nicht das Buch kaufen, sondern kann alles online lesen.) Die Übersetzung ist zum Teil etwas merkwürdig und einige Begriffe interessant. (Finally-Blöcke heißen ›Abschlussroutinen‹ und die Übersetzter deutschen ›modifizier‹ mit ›Modifikatoren‹ ein, während ich sie lieber ›Modifizierer‹ nenne.) Leider passierte ein Fehler auf der ersten Seite der ersten Auflage, dass das Team Mary Campione/Karthy Walrath das Buch geschrieben haben soll. Und solche Fehler tauchen auf, obwohl gleich 7 Personen das Buch übersetzt haben. Dinge, die ich in die Insel noch aufnehmen sollte sind Laden/Verifizieren/Binden. Mir ist auch noch nie eine statische Methode classFinalize() aufgefallen, die eine JVM beim Entfernen (unloading) von Klassen aufgerufen könnte. (Sun schreibt dazu unter http://java.sun.com/docs/books/jls/class-finalization-rationale.html: ›Eliminating this feature has no effect on existing programs, since it was unimplemented.‹) Das interessanteste Kapitel zum Verständnis ist sicherlich ›Das Übersetzen für die virtuelle Maschine‹ auf knappen 26 Seiten. Die ersten 50 Seiten haben nichts mir der JVM an sich zu tun, sondern finden sich wie das Kapitel ›Threads und Sperren‹ auch in der Sprachreferenz. Man hätte auf diese 70 Seiten eigentlich verzichten können. Januar 2k, Dezember 2006

Distributed Java 2 Platform Database Development
Stewart Birnam. Prentice Hall. ISBN 0-13-026861-5. 276 Seiten. 2001
Von allem ein bisschen wie das Buch ›Advanced Programming for the Java 2 Platform‹. Interessanter Überblick für diejenigen, die im Jahr 2000 leben. November 2006

Java Native Interface: Programmer’s Guide and Specification
Sheng Liang. Addison-Wesley. ISBN: 0201325772. 1999. 303 Seiten
Immer noch ganz ordentlich zu lesen, obwohl es mehr Beispiele geben könnte. Zum Glück (ja?) hat bei JNI hat sich wenig verändert, sodass das Buch weiter aktuell bleibt. Um JNI zu lernen kann man das ganze Tutorial bei Sun aber auch online lesenNovember 2006

Inside the JavaOS operating system
Tom Saulpaugh, Charles Mirho. Addison-Wesley. ISBN 0-201-18393-5. 1999. 184 Seiten
Interessant, was sie dich Menschen bei Sun so alles ausdenken. Spricht da heute noch jemand von? November 2006

Client/Server Data Access with Java and XML
Dan Chang, Dan Harkey. ISBN 0471245771. 640 Seiten. 1998
Ein recht altes Buch, was man nicht mehr lesen muss. November 2006

Advanced Programming for the Java 2 Platform
Austin Calvin, Monica Pawlan. Addison-Wesley. ISBN 0201715015. 2000. 381 Seiten
Ein Rundumschlag über diverse Java-Themen wie EJB, RMI, JDBC, Swing um eine Auktionsplattform. Buch gibt’s bei Sun online. Kaufen und lesen lohnt nicht mehr, da es veraltet ist, und es bessere Bücher für die Teilthemen gibt. September 2006.

Java Reflection in Action
Ira R. Forman, Nate Forman. Manning Publications. ISBN 1932394184. 2004. 300 Seiten
Das englische Buch von Manning Verlag von Ira Forman (Vater) und Nate Forman (Sohn) beschreibt auf 300 Seiten und 10 Kapiteln die Reflection-API und assoziierte Themen wie Proxy und Quellcodegeneration. Im ersten Kapitel ›A few basics‹ gehen die Autoren auf die Notwendigkeit für dynamische Aufrufe ein, was im zweiten Kapitel ›Accessing fields reflectively‹ gleich für ein Beispiel zur XML-Serialisierung genutzt wird. Das Kapitel nennt auch die Methode setAccessible() zum Zugriff auf nicht-sichtbare Eigenschaften, doch ein Beispiel zur Konfiguration des Sicherheitsmanager mit der ReflectPermission ›suppressAccessChecks‹ hätte den Abschnitt perfektioniert. Das dritte Kapitel ›Dynamic loading and reflective construction‹ schließt die Grundlagen des Pakets java.lang.reflect mit einer Beschreibung zum dynamischen Klassenladen und das Entwurfsmuster Fabrik ab. Die ersten Kapitel sind sehr ordentlich und zeichnen mit vielen Details ein gutes Bild der Reflection-API; jedes Kapitel im Buch endet mit einem Unterkapitel ›Pitfalls‹ und einer Zusammenfassung. Die nächsten dreißig Seiten des 4. Kapitels ›Using Java’s dynamic proxy‹ veranschaulichen die Klasse java.lang.reflect.Proxy für ein elegantes Mittel zu Umsetzung des Dekorator-Musters.
Kapitel 5 ›Call stack introspection‹ zeigt abseits der Frage, was Klassen können oder Objekte haben, wie der Aufruf-Stack interpretiert werden kann. Als Anwendung nennen die Autoren Logging, Sicherheitsfragen und Kontrollfluss (Rekursion erkennen). Dass Thread seit Java 5 eine Methode getStackTrace() besitzt, auch daher kein explizites Throwable-Objekt mehr nötig ist, erwähnt das Buch nicht, genauso wenig, dass die Java-Security 1.2 auf der Basis von Stack-Inspektion arbeitet. (Die Webseite http://www.developer.com/java/ent/print.php/610811 gibt einen Einblick in die sehr interessante Technik.) Das selbst entwickelte Logging hat in diesem Kapitel leider einen zu hohen Stellenwert.
Das 6. Kapitel ›Using the class loader‹ vermuten Leser nicht einen Buch über Reflection und daher bieten die Autoren eine Begründung an: ›subclassing the class loader is a form of reflection‹. Das ist sicherlich Ansichtssache und genauso subjektiv ist die Notwendigkeit für einen Klassenlader, der statische Attribute initialisiert; auf die Idee würde JUnits TestCaseClassLoader (oder ReloadingTestSuiteLoader) nie kommen. Obwohl lib/endorsed zur Sprache kommt, um Teile der Java-API ohne Änderung vom Bootclasspath auszutauschen, fehlt das offensichtlichere lib/extention und auch der Bootclasspath wird nicht erklärt, obwohl das Kapitel schon relativ ausführlich auf Klassenlader eingeht. Abschnitt 6.4 zeigt, wie ein Klassenlader aussehen muss, damit Klassen ersetzt werden können – ein schönen Beispiel, das Proxy-Pattern mit java.lang.reflect.Proxy-Klasse, Klassenlader und Weak-References zusammenbringt.
Auf das 7. Kapitel ›Reflective code generation‹ war ich am meisten gespannt. Erwartet habe ich die aktuellen Bibliotheken wie CGLIB, Javassist, ASM, BCEL oder Dynclass, bekommen habe ich einen Kommandozeilenaufruf von javac. (Für Java 6 bekommen wir hoffentlich wieder eine neue Buchauflage, denn eine Compiler-API ist angekündigt.) Was dann folgt ist ein Programm, welches Java-Quellcode generiert. Sicherlich eine mitunter nötige Operation für MDA, doch dann würde ich mir eine Beschreibung und Anwendung einer Template-Engine wünschen und kein Java-Quellcode in String-Literalen, der konkateniert in eine temporäre Datei geschrieben wird. Immerhin gibt es noch einen kurzen Bezug zu AOP, doch alles in allem enttäuscht das Kapitel. Gerne hätte ich über einen kompilierten Proxy (net.sf.cglib.proxy.Proxy) gelesen oder über den Bean-Eigenschaften-Kopierer net.sf.cglib.beans.BeanCopier, der nicht wie die Apache Commons BeanUtils bei BeanUtils.copyProperties() über Reflection geht – auch zu dieser sehr schönen Reflection-Anwendung. Große Real-Life Applikationen wie JBoss oder der OR-Mapper Hibernate zeigen einen unverblümten Einsatz der dynamischen Bytecodegeneration, was die Autoren zusammen mit den Tools CGLIB, Javassist, BCEL in einer bescheidenen Fußnote auf der vorletzten Seite des Kapitels aber immerhin erwähnen: ›As evidence, we offer the fact that the builders of powerful tools […] are using cglib […]‹. Die knappe Darstellung reicht in einem Buch über Reflection nicht aus. Auch hilft der Verweis auf andere Büchern wie ›Code Generation in Action‹ – das Javassist, cglib, BCEL noch nicht mal erwähnt – und ›Generative Programming: Methods, Tools, and Applications‹ nicht aus. Dass man Quellcode für ›Design patterns‹ auch generieren kann zeigt das 8. Kapitel. Reflection liest Elemente wie Konstruktoren aus und generiert Singleton, Dekorator und Proxy; die Autoren nennen das ›class-to-class transformation‹. Beim Singleton findet sich ein kleiner Fehler im Text, dass die Autoren annehmen, dass bei clone() nie gilt: ref == ref.clone(). Das ist falsch, denn auch die API-Dokumentation von Sun nennt eine Anwendung bei immutable-Objekten – so liefern beispielsweise die Wrapper-Objekte immer die this-Referenz. Eine Beispielanwendung generiert Quellcode für ein Singleton, obwohl nicht ganz klar wird, was das Beispiel eigentlich zeigen soll. Der folgende generierte Dekorator testet Invarianten, leider fehlt ein Bezug zu modernen AOP-Frameworks, die diese Aufgabe standardmäßig mit simplen Interceptoren lösen. (JBoss AOP verwendet für Framework an vielen Stellen Standard-Reflection.)
Kapitel 9 ›Evaluating performance‹ stellt Micro-Benchmarks vor. Ein Testprogramm misst a) die Laufzeit für direkte Methodenaufrufe, b) Methodenaufrufe durch Proxy-Objekte, die eine Methode direkt aufrufen, und c) Proxy-Objekte, die über Reflection eine Methode aufrufen. Die Autoren kommen für Aufrufe ohne Argumente auf folgende Zahlen: Der direkt anspringende Proxy benötigt etwas mehr als doppelt so viel Zeit wie ein direkter Methodenaufruf. Am Teuersten ist der Aufruf über Reflection: 331 Mal teurer als ein direkter Aufruf. Die Tests wurden unter Windows 2000 mit Java 1.4.1 durchgeführt. Obwohl der Benchmark auf den ersten Blick einen Geschwindigkeitsverlust attestiert, relativieren die Autoren im nachfolgenden Abschnitt die Bedeutung der Zahlen und bringen eine interessante Anwendung von Amdahls Gesetz. Das Kapitel bremst Entwickler, die immer auf Grund von Micro-Benchmarks ihr Design ändern wollen.
Das 10 Kapitel ›Reflecting on the future‹ stellt den Lesern kurz Reflection bei anderen Sprachen vor: C#, Python, Smalltalk, Ruby, Perl. Auf etwa einer Seite schreiben die Formans über Aspektorientierte Programmierung, ohne jedoch Reflection und AOP in einen großen Bezug zu stellen. Weiterhin beschreibt das zehnte Kapitel Eigenschaften von Java 5, auf das eigentlich das Buch hätte bauen sollen. Zwar erklärt das Kapitel Annotationen gut, doch schade, dass das Annotation Processing Tool (apt) nicht genannt wird. Hier müssen die Autoren für die nächste Auflage nachbessern. Drei Anhänge schließen das Buch. Anhang A ›A Reflection and metaobject protocols‹ ist der philosophische Teil. Es geht um Meta-Programme, Meta-Level und Base-Level, um das Modell von Friedman und Wand, um das Meta-Objekt Protokoll. Anhang B geht das Problem mit waitFor() bei extern gestarteten Programmen nach und Anhang C wiederholt zentrale Symbole in UML-Diagrammen. Ein Glossar – wobei die meisten Begriffe aus dem Anhang B stammen – und eine Literaturangabe mit fast 100 Quellen beenden das Buch.
Insgesamt bietet das Buch einen schönen Einstieg in das Reflection-Model von Java und stellt durch den Anhang auch wissenschaftlich ambitionierte Leser zufrieden. Für Entwickler, die sich erstmalig mit Reflection beschäftigen, bringen die ersten Kapitel den meisten Gewinn. Bei einigen Kapiteln (Code-Generation) fehlt die Tiefe, die Entwickler erhoffen. Zumindest drei Kapitel sind im Internet frei zugänglich (Kapitel 1 und 5 unter http://www.manning.com/forman/, Kapitel 4 unter http://www.webreference.com/internet/reflection/) und erlauben einen ersten Einblick. Da das Buch im Oktober 2004 auf den Markt kam, Java 5 aber erst Ende September, lässt sich die Entscheidung für Java 1.4 verstehen. Die Autoren beschreiben zwar im zehnten Kapitel die Neuerungen wie Auto-Boxing, Generics und Variable Argumente, doch in der nächsten Auflage des Buches ist eine konsequente Nutzung in den Beispielen und API-Beschreibungen wünschenswert. Die Reflection-API nutzt Java 5 Eigenschaften reichhaltig:

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 generifiziert und Funktionen wie getMethod() und invoke() ermöglichen variable Argumentlisten. August 2005

Tricks of the Java Programming Gurus
Glenn L. Vanderburg und weitere
Einer der ersten ›Tipps und Tricks‹-Bücher mit 35 Kapiteln. Viele Kapitel wiederholen einfach nur Standard-Wissen, und nur bei wenigen Abschnitten findet man Tricks, die man in einem ›Guru‹-Buch eigentlich erwarten dürfte. Kapitel 1 geht auf Frage ein: Wie kommunizieren Applets? (Context, statische Variablen). Kapitel 2: Wie funktioniert das Laden mit dem MediaTracker? (Der MediaTracker informiert über den Status, was ImageIO nicht tut). Dass der MediaTracker allerdings mehr geworden ist als ein Bilderlader hat sich nicht bestätigt. Im Kapitel 3 folgen Netzwerkthemen: URLURLConnection und Übermittlung via POST, Socket. Das 4 Kapitel handelt über Audio und die Klasse AudioClip. Für heute Applikationen uninteressant mit der Aktualisierung in Java 1.2. Auch das nächste Kapitel ist nicht Tipp-Verdächtig: IO-Streams und RandomAccessFile. Im anschließenden 5. Kapitel werden Threads und die ThreadGroup vorgestellt; auch ein Standard für Standard-Java-Einführungsbücher. Gut ist jedoch ein Bezug auf ein wenig Interna, wie der Verknüpfung von Thread und ThreadGroup und wer da einen Verweis auf wen hält sowie Erklärung der Green-Thread-Implementierung in frühren Java-Versionen. Das 7. Kapitel erweitert dann Threads um die Themen Nebenläufigkeit und Synchronisation — alles Standard-Buchthemen. September 2005

Teach Yourself Internet Game Programming With Java in 21 Days
Michael Morrison. Sams.net. 1996. ISBN 1575211483. 416 Seiten
Ok. Das Buch ist von 1996 und man muss sich mit Java 1 begnügen. Das ist aber nicht meine Kritik am Buch, sondern dass es Java-Standardwissen in einem Buch verbreitet, was sich mit schwerpunktmäßig mit Spiele-Programmierung auseinandersetzen möchte. Das schafft der Autor nicht, denn er reißt lediglich ein paar Teile an, wie Sprites und belässt übriges oft auf sehr niedrigem Niveau; was ist GIF, was ist AI.September 2005

Data Structures and Programming
Liwu Li. Springer-Verlag Berlin Heidelberg. ISBN 354063763X. 1998. 483 Seiten
Leider nur ein Buch, was in Java einführt, aber wenig auf die Datenstrukturen eingeht. Das Buch assoziiert für mich im Wesentlichen Datenstrukturen, aber das ist nur ein kleinerer Teil. Sonst wieder eine Java-Einführung. Die Datenstrukturen sind auch nicht umwerfend, sonst nur die ›Standard-Datenstrukturen‹ ziemlich schwach beschrieben. Lohnt sich in meinen Augen nicht. November 2003

Open Java. Von den Grundlagen zu den Anwendungen
Stephan Fischer, Abdulmotaleb El-Saddik. Springer-Verlag. 1999
Die erste Seite, die ich in diesem Buch aufschlug, enthielt den Satz ›Techniken, wie die automatische Typanpassung sind in Java ausdrücklich verboten.‹ Nach diesem Satz dann der Schock und die Frage, wie es auf den anderen 700 Seiten weiter gehen soll. Im Prinzip in Ordnung. Einige Aussagen verblüffen mich aber doch: ›Das Laufzeitsystem […] geht deshalb sehr sparsam mit den zur Verfügung stehenden Ressourcen um‹. Das zum Thema ›Schnelligkeit‹. Na ja. Auch Objektvariablen als ›lokale Variablen‹ und statische Variablen als ›globale Variablen‹ zu deklarieren irritiert mich. Call-by-Reference, Klassenname 3DPunkt geht doch gar nicht, was soll java.lang.package für ein Paket sein? (es gibt recht neu eine Klasse java.lang.Package, aber die meinte der Autor sicherlich nicht), ›4 instanceof String‹ kompiliert gar nicht erst (seit Java 5 kann man neu darüber diskutieren) und kann nicht false ergeben. Didaktisch Vector und Hashtable vor Schleifen? Hat eine Methode einen Typ? Ok, einen Rückgabetyp, aber Typ alleine? Wie implementieren Java-Versionen vor 1.2 die Schnittstelle Array? Uff. Eine Klasse, die eine Excetion wirft. Das kann doch nicht sein (Seite 139). stop/resume/suspend war schon seit 1.2 auf einer ThreadGroup deprecated. Dann noch so dies oder das. Doch zum Guten. Insbesondere im hinteren Bereich hat das Buch seine Stärken. Ordentlich beschreibt es JavaBeans, JDBC, RMI, CORBA. Das sind allerdings die 66,95 Euro nicht wert (die jedenfalls Amazon verlangt). Oktober 2002

Java Unleashed 1.1
Michael Morrison. Sams. ISBN 1575211971. 1996. 1164 Seiten
Natürlich maßlos veraltet, aber noch mal zum drüberblättern ganz nett. Interessant, was damals schon in den Büchern stand, JavaOS. Hört man heute gar nichts mehr von. Mai 2002

Sprechen Sie Java? Eine Einführung in das systematische Programmieren
Hanspeter Mössenböck. dpunkt-Verlag. ISBN 3898641171. 2001. 299 Seiten
Typisches Uni-Buch. Keinerlei Bibliotheken werden eingeführt. Daher für den typischen Industrieprogrammierer unbrauchbar. Einige Fehler in den Beispielen. Preis: 54,00 DM. November 2001

Java by Dissection: The Essentials of Java Programming
Ira Pohl, Charlie McDowell. Addison-Wesley. ISBN 0201612488. Oktober 1999. 656 Seiten
Durchschnittliches Javabuch. Nicht unbedingt so toll. November 2001

Programmieren mit Java. Das Lehrbuch zum sicheren Umgang mit Objekten
Andreas Solymosi, Ilse Schmiedecke. Vieweg Verlagsgesellschaft. ISBN 3528256974. 2001
Recht günstiges (57,99 DM) Java-Buch zu einer Vorlesung. Etwas didaktisch merkwürdiger Aufbau. Erst auf Seite 200 Steuerstrukturen; sehr fragwürdig. September 2001

Java – plattformunabhängig programmieren
O’Niel Annand Valentin Som. bhv-Verlag. ISBN 3-89360-302-6. 1997, 208 Seiten
Oh Gott. Das darf nicht sein! Das schlechteste Java-Buch in diesem Quartal. Kümmert sich nur um eine lasche Einführung und dann kommt nur noch etwas AWT. Wundert mich überhaupt, dass der Autor das GridBagLayout fast verstanden hat. Sonst seitenweise peinliche Fehler, die mich zur Korrektur zwangen. Einige Beispiele: ›Der erste Buchstabe eines Bezeichners kann […] aber kein Umlaut sein.‹ (Unsinn), ›[…] zugegriffen werden, mit this auf die aktuelle Klasse‹ (Objekt, nicht Klasse ), ›Zur Umwandlung eines Typs in einen anderen ist eine ausdrückliche Aufforderung an den Compiler notwendig […]‹ (Quatsch, nur bei expliziten Typanpassungen), ›Wird eine Methode nicht sondert mit einem […] Modifizierer gekennzeichnet, dann gilt sie als private […]‹ (Natürlich nicht, sie ist paketsichtbar) und so weiter. Mein Liebling ist: ›Nach dem Schlüsselwort synchronized kann eine Variable angegeben werden, die während des folgenden Blockes nicht von anderen Threads aus zugänglich ist.‹ Juli 2001

Einführung in die objektorientierte Programmierung mit Java
Ernst-Erich Doberkat, Stefan Dißmann, Oldenbourg. ISBN 3486247867. 2000. 315 Seiten
Für Studenten mit Erfahrung in anderen Programmiersprachen ganz nett. Hält sich leider nicht an die Java-Namenskonvention. Sonst ein paar nette Algorithmen erklärt. Juli 2001

Java in der Anwendungsentwicklung. Objektorientierung, Verteilung, Datenbanken
Gerald Ehmayer, Siegfried Reich. dpunkt-Verlag. ISBN 3920993845. X Seiten
Altes Buch mit völlig unpassender Titelbeschreibung. Unpräzise und ungenau. Februar 2001

Java
Walter Doberenz. Hanser-Programmier-Praxis. ISBN 3-446-18854-1. 1996. 494 Seiten
Noch so`n schlechtes Javabuch, über das man eigentlich kein Wort verlieren brauch. Dem Zeitpunkt nach zu urteilen eines der frühen Buch auf dem deutschen Markt. Dass es schlampig geschrieben ist, merkt man z.B. an vielen groß geschriebenen Methodennamen in Tabellen (eigene Lieblingseigenschaft von MS-Word). Die letzen Seiten sind ein Quicky durch ein paar FAQs, Implementierungsschnippsel hingeschmiert, ohne große Erklärung. OOP kommt dann auch erst nach allem anderen Java-Typischen. Daher: unbrauchbar.  Januar 2001

Java Gently
Judy M. Bishop. Addison-Wesley. ISBN 0-201-342979. 1998. 508 Seiten
Hach, ich traue mich gar nicht ein schlechtes Wort über dieses Buch zu verlieren, da doch viele Didaktiker mit dem Buch so glücklich sind. An der Uni Paderborn werden die Einführungsveranstaltungen mit diesem Buch gemacht und Herr Kastens hat sogar eine deutsche Übersetzung initiiert. Ehrlich gesagt finde ich diese Buch zwar nicht didaktisch grottenschlecht aber zu einem gut kann ich mich nicht durchringen. Vor mir liegt die zweite Auflage von 1998,die das JDK 1.1 als Unterlage verwendet. Beginnen wir mit der Methodik/Didaktik: <subjektiv on>Die Reihenfolge der Präsentationen der Inhalte finde ich sehr fragwürdig: Grundlagen OOP, Dateieingabe/-ausgabe, if, Exceptions, while/do, switch, Arrays, Formatierungsklassen, OOP, innere Klassen, Abstraktion und Vererbung, GUI, Ereignisse, Applets, Threads, Netzwerke, Algorithmen und DS. Bevor die erste Schleife oder Fallanweisung kommt wird der Leser mit Objekten, Konstruktoren, Konstanten behelligt. So ist es immer ein Mischmasch von Konzepten aber ich erkenne keinen roten Faden. Das heißt aber noch lange nicht, dass das alles nicht zusammenpasst. Das schon. Es ist alles schön aufeinander abgestimmt. Nur glaube ich nicht, dass der Leser dies mit sich machen lässt. Zur Didaktik: Was sie schreibt ist gut, mit schönen Beispielen und Aufgaben. Wenn es anders sortiert wäre ich durchaus glücklich damit. <subjektiv off> Woran aber nichts zu zweifeln gibt sind die unsäglichen Inkonsistenten in der zweiten Auflage. Peinlich. Sie betreffen zum Beispiel die Bezeichnernamen, mal sind Variablen klein/groß, Konstanten immer klein geschrieben, in den kleinen Info-Blöcken mal Schlüsselwörter groß, mal in Fettdruck. Mal Leerzeichen hinter/vor Methoden, mal nicht. Als Buch, welches vorgibt Methodik zu lehren, darf dies nicht passieren. Dann noch einige Ungenauigkeiten in den Bibliotheken. Unter anderem liegt das an der Version 1.1. Es gibt auch eine Float.parseFloat() Methode. Schlimm auch folgende Zeile:

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

Darunter noch mal ein BufferedReader Fehler. Damit genug gesagt. Jetzt geht’s zurück ins Bibo-Regal. Die zweite Auflage habe ich noch nicht begutachtet. Juli 2k

Die Java2 Fibel
Ralf Künel. Addison-Welsey. ISBN 3-8273-1410-0. 1999. 442 Seiten
Vor mir liegt die dritte Auflage des Buches, frisch überarbeitet mit den Features vom JDK 1.2. Leider ist das Buch nicht qualitativ besser geworden, sondern es beschreibt nur einige neue Eigenschaften. Der Einstieg in die Sprache ist ganz ordentlich (ersten 100 Seiten), doch dann geht es etwas schnell. Die eingestreuten Listings irritieren mich. Keine vernünftige Einführung in das AWT und Zeichenoperationen. Didaktisch nicht toll. Das Buch würde ich mir auf keinen Fall kaufen. Wenn man es als Fortgeschrittener einmal in der Hand hat, kann man von 4 Seiten über Schwachen Referenzen profitieren, sonst Finger davon.April 2k

Java 1.2: Java-Tutorial Programmierung von Applikationen, die Schnittstelle zu C und C++, Klassenbibliotheken, ausführliche Referenz
Ralf Steyer. M&T Verlag
Nein, dieses Buch steht hier bestimmt nicht weil ich es toll fand, sondern weil es dermaßen schlecht ist, dass ich die Welt vor diesem Buch warnen muss. (Wer nun allerdings denkt, ich stehe mit meiner Meinung alleine, der sollte mal bei Amazon unter den Rezensionen durchlesen. Wobei ich glaube, die guten Kritiken hat er von seinen Freunden). Das Buch ist so schlecht, dass man auf jeder Seite den Rotstift ansetzen muss. Wie dies überhaupt erst gedruckt werden konnte ist ein Wunder. Und hier sieht man mal wieder, wie der M&T Verlag Kasse machen will. Auf dem Buchrücken steht vollmundig: RMI. Ich fall‘ um; eine Seite. Servlets — 4 Seiten. JDBC 12 Seiten. Und all dies seht vorne drauf und lockt uns an. Nicht besser sieht es mit der nativen Anbindung aus, eine Ankündigung, die schon der Titel des Buches verrät. Hier werden wir mit 14 Seiten nach Hause geschickt. Na ja, und über den Rest brauche ich wohl nicht viele Worte verlieren. 250 Seiten Bla Bla, bis es mal zur Sprachbeschreibung kommt. Gigantische drei Seiten über Swing, obwohl das Buch von 1998 ist, usw. usw. September 1999