Open Source Docking Frameworks

http://lopeathal.wikispaces.com/Open+Source+Docking+Frameworks gibt einen Überblick über Docking-Frameworks:

Name Development Licens Size Comments
MyDoggy active LGPL only jar’s: 0.5 MB
NetBeans active CDDL/GPL 4.6 MB (platform.zip)
XUI active MPL 1.6 MB (XUI-jdk15.zip)
JDocking inactive CDDL 1.3 MB (v0.8.zip) the docking part
of netbeans
JRichClient active GPL heavy development derivation of flexdock
FlexDock inactive community although
there is a new version (bugfix)
MIT only jar’s: 0.5 MB
Sanaware active GPL or Commercial full zip 0.3MB
InfoNode last version January 2007 GPL
VL Docking one year old – inactive? CeCILL/GPL
Eclipse active CPL or EPL ? only swt (?)
Docking Frames active LGPL 2.1 0.7 MB

Thema der Woche: Collection-API

Die Collection-API enthält grundlegende Sammlungen für Listen, Kellerspeicher, Assoziativspeicher. Gehe über alle Operationen der folgenden Schnittstellen:

Finde je ein Beispiel für keySet(), retainAll(), toArray(), headSet().

Welche Implementierungseigenschaften haben die folgenden Klassen:

Fülle eine WeakHashMap mit sovielen neuen java.awt.Point-Objekten, bis es einen OutOfMemoryError gibt. Fange diesen ab und gib die Größe der WeakHashMap aus.

Laufe zum Verständnis der Implementierung folgende Szenerien im Debugger ab:

  • Ein Element wird in die HashMap eingefügt, dann erfragt.
  • In eine LinkedList bzw. ArrayList werden einige Elemente eingefügt, dann nach ihrer Position erfragt und gelöscht.

Buchkritik: 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);

(Wie wäre es stattdessen einfach mit radius * radius * 2? Oder wollte er ein Beispiel für größtmöglichen Rechenaufwand leisten?) Um vielleicht ungenauen Pi-Belegungen von Sun über Math.PI vorzubeugen, ist es auch sinnvoller, gleich selbst PI vorzubelegen: public static final double PI = 3.141;. Ist viel viel besser! Im Kapitel werden auch Bit-Felder vorgestellt inklusive der Bit-Operatoren. Bei den anschließenden Aufzählungen und Konstanten-Objekten baut der Autor dann erst einmal das Java 5 enum nach, bis er schlussendlich im letzten Kapitel auch zu Java 5 kommt. Dann kommt aber doch noch ein interessanter Absatz über readResolve() bei der Serialisierung. Immerhin hat Robert verstanden, dass es Klassenlader gibt: „You may think that since the constant object is final and static, this will guarantee that only one instance of each constant object will be in memory. I used to think the same thing until I was blindsided by a vicious bug in a genetic research system.“ Impressive! Im 8. Kapitel geht’s um Datenmodellierung. Kein Java-Thema und auch nur ein paar Seiten. Der Ansatz: „Unterstreiche alle Nomen und du hast Klassen, unterstreiche alle Verben und du hast Methoden“ darf auch nicht fehlen. So hat Robert sicherlich große Enterprise Systeme modelliert. Kapitel 9 hat Reflection zum Thema und etwas zum java.beans Paket. Seine Lust, an alle möglichen finalen Variablen auch final dranzuschreiben, sinkt. Kapitel 10 kommt auf Proxies zu sprechen, und dass die bei CORBA und RMI vorkommen. Nachdem ein selbstgebauter Proxy sich vorstellen darf, kommt es doch noch zu Einsatz vom InvocationHandler/Proxy. Jetzt wird es langsam interessant. Kapitel 10 spricht von schwachen Referenzen. Er implementiert ein

public class WeakHashSet extends AbstractSet implements Set

(warum steht hier implements Set?) und schreibt einen Weak-Listener. Solch ein Konstrukt ist insbesondere in Swing-Anwendungen sehr nützlich, doch hier hätte ich den Hinweis gut gefunden, dass etwa die OpenIDE, also NetBeans, hier schon etwas anbietet. Wo jetzt andere „Hardcore“-Bücher einsteigen ist seines, oh schade, schon zu Ende. Das war eigentlich das letzte Kapitel! Denn Kapitel 12 ist das Abschlusskapitel mit Java 5 und geht auf die Neuerungen ein. Doch seien wir ehrlich: Harte Nüsse wie Generics lassen wir uns viel lieber von einem echten Crack, von Joshua Bloch, in seinem Buch erklären. Dann müssen wir uns nicht Beispiele wie dieses hier anschauen:

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

Typvariablen sollten immer nur aus einzelnen Großbuchstaben bestehen. Bei einer Deklaration wie Type getValue() sieht sonst Type wie ein ordinären Java-Typ aus. Und warum wird value mit null initialisiert. Das ist doch klar, dass die JVM das mit null belegt. Was zeigt das Buch? Immerhin das O’Reilly den Mut hat, die schlechten Bewertungen auf der Webseite stehen zu lassen und nicht zu löschen. Meine Hochachtung. Bei Amazon sind die Bewertungen aber noch ehrlicher. Mut wird O’Reilly erst dann wirklich beweisen, wenn sie a) den Titel umformulieren, b) sich einen neuen Autor suchen, der das Buch umschreibt bzw. erweitert oder c) – die beste Option für jetzt – das Buch aus dem Sortiment nimmt. 4 Jahre nach Erscheinen wird’s Zeit dafür.

Buchkritik: JavaScript: The Good Parts

Douglas Crockford. O’Reilly. ISBN 978-0-596-51774-8. Mai 2008. 170 Seiten

In meinem Alltag habe ich wenig mit JavaScript zu tun (von meinem Visual Foxpro nach JavaScript-Konverter einmal abgesehen), sodass mir das Buch gerade recht kam, um meine JavaScript-Kenntnisse zu vertiefen. Es ist sicherlich nicht für absolute Anfänger geschrieben, doch für Leser mit Grundkenntnissen gut geeignet, tiefer in die Sprache einzusteigen. Techniken wie den Prototyp-Ansatz der Objektorientierung beschreibt Douglas sehr genau, sicherlich etwas zu detailliert für diejenigen, die nur  mal eben" JavaScript für die Webseite einsetzen möchten. (HTML und DOM spielen kaum eine Rolle. JavaScript wird eher als allgemeine Programmiersprache behandelt und weniger als  Webseitensprache".) In seine Beispielen finde ich teilweise den Rückgriff auf Variablen und Methoden aus vorangehenden Beispielen etwas irritierend. Zum Beispiel kommt seine selbstgebaute beget()-Funktion immer wieder vor, doch ohne einen Verweis für Leser, die erst in der Mitte einsteigen und diese Funktion nicht kennen. Seiner Argumentation beim Inkrement-/Dekrement-Operator ++, –, "In my own practice, I observed that when I used ++ and –, my code tended to be too tight, too tricky, too cryptic. So, as a matter of discipline, I don’t use them any more. I think that as a result, my coding style has become cleaner." bei den Bad-Parts kann ich nicht folgen, doch sonst erscheinen mit die Bad- und Awfull-Parts recht sinnvoll ausgewählt. Der
Unterschied zwischen == und === enthält tolle Beispiele; Begründungen für die Auswertung wären allerdings schön.

'' == '0'          // false 
0 == ''            // true
0 == '0'           // true
false == 'false'   // false
false == '0'       // true
false == undefined // false
false == null      // false
null == undefined  // true
' \t\r\n ' == 0    // true

Im Anhang stellt der Autor JSLint vor, ein Tool zum Testen der Codequalität von JavaScript-Programmen. Das ist zwar nett, doch hätte

ich freie JavaScript-Bibliotheken (wie etwa Prototype) lieber gesehen. Das Kapitel 4 (Functions) gibt’s online.

PersistJS: Lokal im Browser Daten speichern

Zustände von Web-Applikationen können, sofern sie klein sind, im Cookie gespeichert werden. Alles, was jedoch größer als 4 KB ist, wird in der Regel auf der Serverseite abgelegt. Nun haben in den letzten Jahren die Browser-Hersteller lokale Speichermöglichkeiten entwickelt:

  • globalStorage: Firefox 2.0+, Internet Explorer 8
  • localStorage: development WebKit
  • openDatabase: Safari 3.1+
  • userdata behavior: Internet Explorer 5.5+

Daneben gibt es Plugins, etwa von Google (Gears) oder Yahoo. Das dumme bei den Plugins ist jedoch, das diese extra installiert werden müssen. Ihr Vorteil allerdings: Eine standardisierte API. Doch damit kann nun Schluss sein. Mit PersistJS gibt es eine standardisierte API, die von den jeweiligen Browser- und Plugin-APIs abstrahiert. Der Zugriff ist simpel

var store = new Persist.Store('Mein Data Store');
var data = "Daten";
store.set('saved_data', data);
store.get('saved_data', function(ok, val) {
if (ok)
alert('saved data = ' + val);
});
store.remove('saved_data');

PersistJS nutzt nun intern:

  • flash: Flash 8 persistent storage.
  • gears: Google Gears-based persistent storage.
  • localstorage: HTML5 draft storage.
  • whatwg_db: HTML5 draft database storage.
  • globalstorage: HTML5 draft storage (old spec).
  • ie: Internet Explorer userdata behaviors.
  • cookie: Cookie-based persistent storage.

Buchkritik: Pro Netbeans IDE 6. Rich Client Platform Edition

Adam Myatt. Apress. ISBN 978-1-59059-895-5. Februar 2008, 491 Seiten

Ein aktuelles Buch über NetBeans, welches auf grundlegende aber auch erweiterte Eigenschaften der Entwicklungsumgebung eingeht. Themen sind unter anderem Installation (das 1. Kapitel "Downloading, Installing, and Customizing NetBeans" ist auch online), der Editor, Einstellungen, Projektangaben, Gui-Bilder, Debugging, Profiling, Versionsmanagement, JUnit, Refactoring, Datenbankbrowser, Qualitätsprüfung. Dass das Buch auf der aktuellen Version 6 aufbaut, zeigt sich insbesondere an den letzten Kapiteln, in denen es JRuby und Rails, Web-Services, BPEL, REST, dem Swing-Application Framework und Beans Binding zur Sprache bringt. Dem Autor ist das Kapitel über Swing aber lieber gewesen, denn hier beschreibt er ausführlicher die Technologie, während bei Web-Services nur Einträge in den Dialogen aufgezählt werden, aber nicht erklärt wird, was diese eigentlich sollen. Aber das ist wohl immer der Fall, wenn ein Buch nur zeigen möchte, WIE man mit der IDE etwas macht, aber nicht warum. Für welche Käuferschicht das Buch am Besten geeignet ist, ist schwer zu beantworten. Erfahrene Entwickler, die schon einige IDEs kennengelernt haben (Eclipse, JDeveloper, …) werden mit NetBeans keine Probleme haben. (Aus der Java-Community gibt es vielfach die Meinung, NetBeans ist viel einfacher zu bedienen als Eclipse.) Daher bekommt man mit etwas Rumklicken und aufmerksamem Lesen die meisten Sachen schnell raus, zumal die Webseite von Sun voll von Tutorials insbesondere für die fortgeschrittenen Themen ist. Wer ein Gespür für Entwicklungswerkzeuge hat, und gerne Online-Tutorials liest, wird mit http://www.netbeans.org/kb/ auch glücklich. Zumal bei Sun Artikel zur Java ME-Entwicklung, C(++) oder UML-Modellierung stehen, die das Buch überhaupt nicht ankratzt. Schade eigentlich, denn vermutlich dürfte UML für die meisten Leser interessanter sein als einen BPEL-Web-Service auf Glassfish zu deployen. Das letzte Kapitel „Developing Rich Client Applications“ hat aber nichts mit der Entwicklungsumgebung selbst zu tun, sondern stellt kurz das NetBeans RCP vor. Hier ist die Zielgruppe eine völlig andere. Denn der Bediener einer IDE ist nicht unbedingt einer, der mit dem RCP Desktop-Anwendungen schreibt. Sehr fragwürdig ist daher auch der Titel „ Rich Client Platform Edition“; hier ist man verleitet anzunehmen, dass es ein Buch über das RCP-Framework ist. Doch nein, es ist nur ein Buch über die Bedienung einer Entwicklungsumgebung.

JPA for Amazon SimpleDB 0.4-Update vom 20.4.

Ein abgefahrendes Projekt ist eine JPA-Schnittstelle für die Amazon SimpleDB (Amazon S3 (Simple Storage Service)). Mit http://code.google.com/p/simplejpa/ lässt sich auf die Amazon-Datenbank über das standardisierte JPA zugreifen. Die Doku unter http://code.google.com/p/simplejpa/wiki/GettingStarted listet alles nötigen Jar-Dateien auf und zeigt anhand eines kleines Beispiels die Nutzung. Da die Amazon-DB keine "richtige" relationale DB ist, gibt es auch einige Einschränkungen, etwa "Can only query on a single object type, no joins." Auf der anderen Seite:

Cargo: Automatisch Web-/JavaEE-Container starten/stoppen und Module Deployen

Cargo (von Vincent Massol) bietet Java-APIs sowie Ant und Maven Unterstützung, um Web- und Java EE-Container zu starten/stoppen und Module zu deployen. Die Liste der Server ist erst einmal toll: Geronimo, JBoss, Jetty, Resin, WebLogic, Tomcat (kein WebSphere!). So gut die Idee auch ist, leider ist das Projekt soweit gestorben. Wer Lust hat, darf gerne project lead werden. Na ja, die letzte Version ist von 10/03/07 und bisher hat sich noch keiner gefunden.

Paket sun.jvmstat: Wie man selbst ein jps schreibt

jps (Java Virtual Machine Process Status Tool) ist ein Utility, welches neu bei Java 5 ist. Es zeigt die aktuellen laufenden Java VM-Instanzen an.

$ jps 
2256
2960 Jps

$ jps -mlvV
1692 sun.tools.jps.Jps -mlvV -Dapplication.home=C:\Programme\Java\jdk1.6.0 -Xms8m
2256 -Xbootclasspath/a:C:\PROGRA~1\Java\JRE16~1.0\lib\deploy.jar;C:\PROGRA~1\Java\JRE16~1.0\lib\plugin.jar -Xmx96m ...

Um ein eigenes jps zu schreiben ist, ist das Java-Archiv tools.jar aus dem lib-Verzeichnis des JDK im Klassenpfad nötig. Dort gibt es das zentrale (interne!) Paket sun.jvmstat.

import java.util.Set;
import sun.jvmstat.monitor.*;

public class T
{
@SuppressWarnings("unchecked")
public static void main( String[] args ) throws Exception
{
MonitoredHost monitoredhost = MonitoredHost.getMonitoredHost( "//localhost" );
for ( int id : (Set<Integer>) monitoredhost.activeVms() ) {
VmIdentifier vmidentifier = new VmIdentifier( "" + id );
MonitoredVm monitoredvm = monitoredhost.getMonitoredVm( vmidentifier, 0 );
System.out.printf( "%d %s %s %s%n", id,
MonitoredVmUtil.mainClass( monitoredvm, true ),
MonitoredVmUtil.jvmArgs( monitoredvm ),
MonitoredVmUtil.mainArgs( monitoredvm ) );
}
}
}

Die Ausgabe ist

2984  -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx512m -XX:MaxPermSize=256M null 
360 T -Dfile.encoding=Cp1252 null
2256 -Xbootclasspath/a:C:\PROGRA~1\Java\JRE16~1.0\lib\deploy.jar;C:\PROGRA~1\Java\JRE16~1.0\lib\plugin.jar -Xmx96m ...

Nützlich kann das ganze sein, um etwa herauszufinden, ob schon ein Exemplar des aktuellen Programms läuft. Denn das zweite Programm findet über mainClass() zweimal die gleiche Klasse.

Thema der Woche: Google Web Toolkit (GWT)

Das Google Web Toolkit (GWT)  ist ein Web-Framework, mit einem interessanten Ansatz. Statt HTML-Seiten in den Vordergrund zu setzen, schreibt man Gui-Anwendungen in Java mit einer in AWT/Swing bekannten Art (Komponenten/Container und Listener) und lässt diese Anwendung von einem Compiler in JavaScript übersetzten. Die ganze Gui wird somit Teil des Web-Browers. Für den Teil, der nicht im Browser läuft, also die gesamte Geschäftslogik und Datenbank, gibt es eine RCP-Schnittstelle.

Schaue drei Beispiele für die Möglichkeiten von GWT an.

Um etwas mehr vom Hintergrund zu verstehen, kann man http://www.maximilien.org/presentations/2006/AJAX_and_GWT_Public_07052006.pdf lesen.

Wer praktisch spielen möchte, kann GWT+Eclipse+Plugin nach dem folgenden Blog-Eintrag installieren. Mehr über die Gui-Komponenten erfährt man in einem Kapitel des Hanser-Verlags (Übersetzung von GWT in Action): Widgets (deutsch).

Swing-Komponenten: JIDE Common Layer

JIDE ist ein Unternehmen, welches schon seit vielen Java qualitativ hochwertige Swing-Komponenten baut. Einige der Komponenten sind frei (JIDE Common Layer (Open Source Project)), weitere wie das Docking-Framework, Action Framework, (Pivot) Grids, Code Editor und weitere gehören zum kommerziellen Teil. Die Komponenten aus dem JIDE Common Layer stehen unter dual-license: GPL und free commercial license.

Textbox, die sich automatisch erweitert

Tabelle und Liste mit Checkboxen, Split-Pane mit mehreren Bereichen


Neue Border und Border-Layout mit anderer Anordnung Norden und Süden


Button-Gruppe und Datums, Popupmenü verbreiterbarer Größe und Zeit/Datum-Auswahl



Neue Standard-Dialoge

Verzeichnisauswahl

Overlay legt Komponenten über andere Komponenten

Scrollpane mit Platz für weitere Komponenten, Slider mit zwei Enden


Container mit Suche und Selektion

Statt Scrollbar automatisches Scrollen durch Pfeile

Diverse Label

Reiterkomponente

Buchkritik: Java EE 5 Development using GlassFish Application Server

David Heffelfinger. Packt Publishing. ISBN 1847192602. Oktober 2007. 408 Seiten

Trägt ein Buchtitel eine Technologie und gleichzeitig ein Produkt im Namen, ist das eine schwere Mischung. Entweder wird auf die Administration des Servers eingegangen, oder wir finden ein Lehrbuch, das nur Beispiele lauffähig auf einem speziellem Produkt vorweisen kann. Heffelfingers Werk gehört in keine Kategorie. Der Bezug zu Glassfish ist minimal, und wer mehr sucht als eine kleine Installationsanweisung – die es auch im Netz bei Sun gibt –, wird enttäuscht. Da die sauberen Java EE Beispiele den Entwickler nicht an einen speziellen Container binden, sind seine Quellcodes auch auf JBoss oder Geronimo ablauffähig. Wer nun Java EE lernen möchte, ist sicherlich darin interessiert, seine Beispiele zumindest auf einem Server laufen zu sehen. Aus Sicht der Zielgruppe eines Buches wohl eher unnötig einschränkend.

Didaktisch und fachlich gibt es das ein oder andere zu bemängeln. Einige Quellcode-Snippets bekommen ihr @Override vor den überschriebenen Servlet-Methoden, andere nicht. Und warum wird der String-Konstruktor laienhaft verwendet?

application.setAttribute("applicationAttribute", new String( "This string is accessible accross sessions."));

Oder parameterName aus String deklariert, aber später dennoch einmal explizit gecastet?

String parameterName = (String) initParameterNames.nextElement();
out.print(config.getInitParameter((String) parameterName));

Oder ein StringBuffer statt der guten allen String-Konkatenation eingesetzt?

@Override public String toString() {
StringBuffer fullNameBuffer = new StringBuffer();
fullNameBuffer.append(firstName);
fullNameBuffer.append(" ");
fullNameBuffer.append(lastName);
return fullNameBuffer.toString();
}

Hier ist ein return firstName + " " + lastName; doch wirklich angenehmer zu lesen und auch die Performance gar nicht schlechter.

Ebenso heiße ich es nicht für sinnvoll, auf das MVC-Konzept auch bei JSP/Servlets zu verzichten. Didaktisch dürften JSPs eher vor Servlets Sinn ergeben. JSPs gehen mir auch zu früh runter auf implizite Objekte und eine Skriptlet-Ebene ohne früh schon EL und die Standard-TagLib zu erklären. Die web.xml-Datei bekommt auch immer unterschiedliche Schema-Dateien und Versionen untergeschoben: Einmal 2.4, dann wieder das aktuelle 2.5. Beim Fehlerhandling findet sich:

StringWriter stringWriter = new StringWriter();
PrintWriter printWriter = new PrintWriter(stringWriter);
exception.printStackTrace(printWriter);
out.write(stringWriter.toString());

Warum der Autor nicht einfach exception.printStackTrace(new PrintWriter(out)); schreibt, ist mir ein Rätsel. (out ist ein JspWriter extends Writer und printStackTrace() möchte einen PrintStream oder PrintWriter.) Dann ist die Definition einer Bean falsch: „All of its variables must be private.” Die von Properties verwendeten Attribute sind in der Regel private, aber sie müssen es nicht sein. Auch sind natürlich public static final-Konstanten erlaubt. (Wunderbar, dass ausgerechnet im zugehörigen Beispiel die Variablen nicht private sind, sondern paketsichtbar.)

Die Datenbank ist mit zehn Tabellen vielleicht für Einstiegerbeispiele doch etwas zu kompliziert. Als Leser ist man erschrocken, plötzlich ein Servlet zu sehen, welches an die Datenbank geht und SQL-Anweisungen ausführt. Warum sieht man so einen Wahnsinn noch im Jahre 2008? Die Datenbank-Connection wird zudem nicht korrekt im finally-Block geschlossen. Es reicht, auf Seite 120 gebe ich auf und wage den Wiedereinstieg auf Seite 347. (Übersprungen werden Standard TagLibs, JSF, JMS, Security, EJB, Web-Services.) Zum Abschluss ein kleiner Höhepunkt: Heffelfinger geht praktisch auf Facelets ein und zeigt auch ein Beispiel für das Templating, ein Weiteres für Ajax4jsf und JBoss Seam findet sich ebenso. Ein erneuter Lichtblick: Der Autor verwendet vorbildlich die vorgesehene Dateieindung .jspf für inkludierte JSP-Fragmente. Dann noch etwas IDE-Integration (NetBeans und Eclipse) und der Spuk ist vorbei.

Buchkritik: 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.

Buchkritik: Agile Java Development with Spring, Hibernate and Eclipse

Anil Hemrajani. Sams. ISBN 0-672-32896-8. Mai 2006. 360 Seiten

Lehrbücher, die anhand eines Beispiels versuchen, die agile testgetriebene Softwareentwicklung mit Ant, Hibernate, HSQLDB und Spring (Web mit Spring MVC) zu zeigen, gibt es meines Wissens keins – bis auf dieses. Vielleicht ist das auch kein Wunder, denn schon die Themen Spring/Hibernate füllen dicke Bücher. Hemrajanis Buch will aber gar nicht in die Tiefe gehen, sondern zeigt, wie mit Open-Source Tools ein Online Timesheet System aufgebaut wird. Der Autor streift dabei weitere Technologien, wie die Eclipse IDE, Logging, Profiling, und stellt Links zu vielen Tools übersichtlich am Ende jedes Kapitels vor. Die Zielgruppe für das Buch dürften Personen sein, die bisher mit dem Standard Java gearbeitet haben, und nun lernen wollen, mit welchen Enterprise Technologien sich Web-Anwendungen bauen lassen. Wer eine detaillierte Beschreibung in JUnit, Hibernate und Spring sucht, ist mit dem Buch sicherlich nicht gut beraten. Schade ist auch, dass Hibernate über die HBM.XML-Dateien konfiguriert wird und nicht die Sprachmöglichkeiten über Java 5 (Annotationen) und der JPA-Entity-Manager zum Einsatz kommen. Dass nicht Spring 2 den Kern bildet, ist zu verschmerzen, und das statt Spring MVC nicht Spring WebFlow zum Einsatz kommt ist wohl eher eine Frage des didaktischen Wegs und dem Zeitpunkts des Drucks zu verschulden.

Thema der Woche: Bug-Finder

Bei jedem Software-Projekt sollte die Qualität über einen langen Zeitraum konstant hoch sein. Insbesondere bei wechselnden Team-Mitgliedern kommen aber schnell Inkonsistenzen in die Sourcen und die Qualität leidet. Code-Analyse Tools versuchen aufgrund bekannter Fehler-Pattern genau diese Schwachstellen zu finden. In Java gibt es eine ganze Reihe von Tools. So führt http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#Java auf:

  • Bandera — analyzer for Java
  • Checkstyle — analyze Java and apply coding standard
  • Classycle — analyze Java class cycles and class and package dependencies (Layers)
  • FindBugs — an open-source static bytecode analyzer for Java (based on Jakarta BCEL).
  • Jlint — for Java
  • PMD (software) — a static ruleset based Java source code analyzer that identifies potential problems.
  • Soot — A Java program analysis and compiler optimization framework

Für einige Produkte gibt es Eclipse-Plugins. Teste FindBugs in Eclipse/NetBeans. Studiere die Bugs/Schwachstellen, die FindBugs automatisch finden kann.

BGGA Closures werden wohl das Rennen in Java 7 machen

Beim http://openjdk.java.net/ Projekt ist ein Unterprojekt http://openjdk.java.net/projects/closures/ eingerichtet worden:

This goal of this Project is to produce a feature-complete prototype of the Java bytecode compiler (javac) for the draft BGGA Closures specification. This Project is sponsored by the OpenJDK Compiler Group.

Wenn es also Closures in Java schaffen — einige Stimmen sagen, dass es dafür noch zu früh ist — dann wohl diese Syntax. Da das Projekt sehr neu ist, befinden sich in der Mailing-Liste noch nicht viele Nachrichten.

Derweil hat sich die Closures-Spezifikation (Homepage http://www.javac.info/) von der Version 0.5 nicht weiter bewegt und auch die Open Issues sind nicht geklärt.

Interessant ist auch die http://www.javac.info/google-position.html (Neal Gafter ist Angestellter bei Google)

As of April 7, 2008, the following is Google’s position on proposals to add support for closures to Java: Google believes Java platform will likely benefit from continued research into closures. To arrive at the best solution, Google is open to multiple parallel investigations but is not currently prepared to commit to any particular proposal. We do not expect these investigations to yield results in time for Java 7, and are of the opinion that it is premature to launch a JSR that forces us down any specific path.

Annotationen in Spring 2.0/2.5 für Autowire und neue Beans

Bis Spring 2.0 gab es im Wesentlichen nur eine Möglichkeit, Spring-Beans zu deklarieren und Bean-Referenzen zu injizieren. Ab Spring 2.0 und besonders in Spring 2.5 gibt es einen Richtungswechsel. Statt Bean-Definitionen und Injizierungsanweisungen ausschließlich über XML-Dokumente zu beschreiben, kommen Annotationen hinzu. Spring nutzt zum Einen Standard-Annotationen aus Java 6 (Common Annoations) aber auch eigene.

Nehmen wir zwei Beans an:

    <bean id="today" class="java.util.Date" /> 
<bean id="calendarPrinter"
class="com.tutego.spring.annotation.CalendarPrinter" />

Die Bean CalendarPrinter soll ein Datum injiziert bekommen.

    public class CalendarPrinter { 
public void setDate( Date date ) …

Über XML lässt sich das einfach beschreiben, doch seit Spring 2.5 veranlasst eine Annotation Spring dazu, die Verweise automatisch zu injizieren:
@Autowired

@Autowired ist eine Annotation für Methoden und Attribute, damit Spring selbständig den Verweis setzt:

    public class CalendarPrinter { 
@Autowired
public void setDate(@Qualifier("today") Date d) …
}

Die Annotation @Qualifier ist nur dann nötig, wenn es mehrere Beans dieses Typs gibt. (Nicht bei uns.)

Damit Spring überhaupt die Verknüpfung vornimmt, ist in der XML-Datei ein Hinweis zu setzen.

Die erste Möglichkeit ist:

    <bean class="org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor"/>

Eine im Allgemeinen bessere Alternative (die AutowiredAnnotationBeanPostProcessor und CommonAnnotationBeanPostProcessor zusammenfasst) ist

    <context:annotation-config/>

Die Annotation @Autowired ist genauso gültig bei Attributen:

    public class CalendarPrinter 
{
@Autowired Date date;

      public void doIt()
      {
        System.out.println( date );
      }
    }

<beans xmlns="http://www.springframework.org/schema/beans" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-2.5.xsd">
<context:annotation-config/>
<bean id="today" class="java.util.Date" />
<bean id="calendarPrinter" class="com.tutego.spring.annotation.CalendarPrinter" />
</beans>

Java 6 (für Java 5 ist ein Extra-Jar nötig) führt aus JSR-250 die Lebenszyklus-Annotationen @PostConstruct und @PreDestroy sowie @Resource ein.

    public class CalendarPrinter { 
@PostConstruct public void initialize() {
System.out.println( "init" );
}
/* @PreDestroy public void remove() {
System.out.println( "destroy" );
} */
}

Beans deklarieren

Die Verknüpfung ist durch Autowire automatisiert und minimiert die XML-Konfigurationsdatei.
Zum Deklarieren von neuen Beans bringt Spring ebenfalls Annotationen mit.
Statt in der XML-Datei zu schreiben

    <bean id="calendarPrinter" class="com.tutego.spring.annotation.CalendarPrinter" /> 

können wir annotieren:

    @Component class CalendarPrinter

Damit Spring nach annotierten Beans sucht, ist nötig:

    <context:component-scan base-package="com.tutego.spring" />

Die Annotation @Component ist an allen Typen erlaubt und natürlich zur Laufzeit sichtbar:

    @Target(value=TYPE) 
@Retention(value=RUNTIME)
@Documented
public @interface Component
{
String value();
}

API zur Eigenschaft: „The value may indicate a suggestion for a logical component name, to be turned into a Spring bean in case of an autodetected component.“

Geben wir dem CalendarPrinter den Bean-Namen „ cal-printer“:

    @Component("cal-printer") 
public class CalendarPrinter

Aus dem ApplicationContext genommen folgt:

    ApplicationContext context = 
new ClassPathXmlApplicationContext( … );
Object bean = context.getBean( "cal-printer" );
System.out.println( bean.getClass() );
// class com.tutego.spring.annotation.CalendarPrinter

@Component ist eine sehr allgemeine Annotation.

Besser ist es, semantische Annotationen zu nutzen, die @Component erweitern. Spring liefert drei mit:

  1. @Target(value=TYPE) … @Component
    public @interface Repository
  2. @Target(value=TYPE) … @Component
    public @interface Service
  3. @Target(value=TYPE) … @Component
    public @interface Controller