Vor paar Tagen, nach dem Rauskommen des fünften Meilenstein von Eclipse 3.1 haben wir beschlossen, das Nutzen der neuen Java 5 Sprachelemente im Projekt zu eruieren. Schließlich benutzen wir JDK5 schon paar Monate ohne Probleme.

Sehr bald haben wir festgestellt, dass die Version 1.1.2 von XDoclet, die wir verwenden, den Tiger noch nicht gezähmt hat.

Das ist ein Problem, das uns vor ein Dilemma stellt: Sollen wir auf die neuen Fähigkeiten von Java 5 wie die Generics, die vereinfachte for-Schleife, um nur die für uns attraktivsten zu nennen, noch verzichten und warten bin XDoclet 1 Java 5 lernt? Oder sollten wir auf XDoclet 2 umsteigen und unsere Plugins umschreiben? Oder sollten wir nach einer alternativen Möglichkeit, aus Metadaten Code zu generieren, suchen? Den eines stand fest, ohne XDoclet oder eine ähnliche Komponente in unserem Build-Prozess, wäre unsere Produktivität nicht zu halten. Nicht mal mit der verbesserten for-Schleife :-)

Nach einer kurzen Recherche auf der Homepage von XDoclet 1 habe ich die erste Möglichkeit verworfen. Die Seite scheint nicht mehr gepflegt zu sein, die Wiki-Seite wird ausschließlich von Wiki-Spammern benutzt (eine Schande!). XDoclet 1 ist Geschichte. Eine glorreiche, aber eine Geschichte.

Die Seite von XDoclet 2 sieht zwar besser aus, allerdings scheint sie sich noch im Aufbau zu befinden. Mir ist durchs Lesen der Seite nicht gelungen herauszufinden, ob XDoclet 2 mit Java 5 Quelltexten umgehen kann. Bevor ich diese Möglichkeit tiefer erforsche, werfe ich lieber einen Blick auf die Alternativen.

Annotations als Alternative zu den XDoclet-Tags

Ein neues Element unter den Sprachmitteln von Java, sind die Annotations. Durch die direkte Unterstützung des Compilers und der IDEs, wären sie sicherlich besser geeignet, die Metadaten in Quelltexte einzubetten, als JavaDoc-Tags. Und mit Reflection kann man auf die Annotations sogar zur Laufzeit zugreifen... Nur hilft uns das nicht bei unserem Problem. Wir wollen nicht, zur Laufzeit auf die Annotations zugreifen, wir wollen zur Build-Zeit die Quelltexte parsen, und anhand der Metadaten neue Quelltexte und andere Dateien wie EJB-Deployment-Deskriptoren, die Hivemind-Konfigurationsdateien usw. generieren.

Wir brauchen also einen Parser, der Java 5 Quelltexte analysieren kann, sich gut in unsere Build-Prozesse integrieren lässt, und der sich leicht zum Generieren von Quelltexten und andere Dateien benutzen lässt.

Netterweise gibt es genau das, was wir brauchen, in dem JDK 5.0. Der Annotation Processing Tool ist ein rekursiv arbeitende Java-Compiler, der die Klassen kompiliert und danach eigenentwickelte Plugins aufruft, die aus den bereits geparsten Quelltexten, neue Dateien und Quelltexte generieren können. Wenn nicht anders angegeben, kompiliert APT die neuen Quelltexte anschließend und startet eine weiter Generierungsrunde. Das so lange, bis keine Quelltexte mehr generiert werden.

Was ist aber mit den XDoclet-Plugins, die wir bisher benutzt haben?

Wir haben bisher neben dem EJB-Doclet hauptsächlich eigene XDoclet-Plugins verwendet. Und da wir nur stateless Sessionbeans verwenden, brauchten wir auch nicht den vollen Umfang von EJB-Doclet.

Es hat sich gezeigt, dass drei Tage gereicht haben, um unsere ganze XDoclet-basierte Codegenerierung auf APT umzustellen. Die APT-API ist einfach, und eigene Annotation-Prozessoren zu schreiben geht sehr schnell.

Fazit

Nun benutzen wir XDoclet in unserem Projekt nicht mehr. Es war eine schöne Zeit, XDoclet hat für uns gute Dienste geleistet, die aktuell zur Verfügung stehen Versionen erfüllen unsere Anforderungen jedoch nicht mehr. Wenn man JDK 5.0 einsetzen kann, ist APT eine attraktive Alternative. Für ältere JDKs ist aber XDoclet immer noch ein wertvolles Werkzeug.

Es wäre schön, die aktuellen XDoclet-Plugins (seien es die für XDoclet 1 oder XDoclet 2) auf APT-API portiert zu sehen. Es wäre schön, statt „Good Bye“ lieber „Auf Wiedersehen XDoclet“ sagen zu können.

... jetzt noch Oracle Toplink überzeugen...