In einem Kommentar bei dem Hinweis von Adam Bien auf dieses Quickvote verweist jemand auf die Entwicklung bei Google. Schaut man sich also diese Entwicklung bei Google innerhalb Deutschlands an so erhält man noch einen deutlicheren Vorsprung von Eclipse, der allerdings über die letzten Jahre deutlich weniger geworden ist:

Die Charts auf Google Insights for Search kann man auch einbetten, was ich doch direkt mal ausprobieren musste:

Insgesamt kann man an der Umfrage und dem Chart gut erkennen, dass Eclipse nicht mehr ganz die alleinige Herrschaft hat bzw. sie langsam verliert. Ich hatte vor Jahren mal NetBeans ausprobiert, war damals aber nicht so begeistert und bin deswegen auf Eclipse umgestiegen. Auch in meinen bisherigen Projekten wurde eigentlich ausschließlich Eclipse verwendet. Vielleicht sollte man sich aber dennoch mal wieder NetBeans anschauen. Aktuell habe ich davon gelesen, dass die JSF 2 Unterstützung darin schon sehr gut sein soll. Ich werde wohl dennoch erst einmal weiterhin ein Unterstützer von Eclipse sein =).

(via Adam Bien)

Das Problem ist, dass zu oft in Projekten herumgewurschtelt wird,
Doku Mangelware und ein Modell oftmals gar nicht oder nur aus der
Anfangsphase vorhanden ist.

Und das wird dann vom Projektleiter stolz als “agile Entwicklung”
verkauft.

Der Java Trendbarometer, bzw die Kommentare bei der Erhebung, nennt diese Entwicklung “Chaos-driven” und “pseudeagli” und hat damit wohl nicht ganz unrecht. Der Java Trendbarometer wird von der Firma expeso erhoben und zwei mal jährlich veröffentlicht und im Juli ist der aktuellste nun veröffentlicht worden.

Zurück zum agilen Vorgehen. Es wurde nach der typischen vorgehensweise im Entwicklungsprozess gefragt und wie selbstverständlich hat “agil” gewonnen:

Das Thema der Vorgehensweisen ist auch das am häufigsten und wohl konroversesten diskutierte Thema.

Nun aber ein paar interessante Grafiken rund um Java. Die Frage nach der Häufigkeit der verwendeten Java Versionen zeigt, dass JDK 1.4 doch so langsam immer weniger wird.

In der JavaEE Welt bestimmen allerdings immer noch die Altlasten bzw. die in den letzten Jahren mit J2EE erstellten Enterprise Anwendungen den verwendeten Standard. Hier ist die Migration oder Neuentwicklung deutlich teurer als das Beibehalten der funktionierenden Anwendung.

Persönlich glaube ich allerdings, dass in den nächsten Jahren die Kurve für JEE, gerade mit der JEE 6 Spezifikation, deutlich nach oben gehen wird.

Die Frage nach der Entwicklungsumgebung finde ich auch sehr interessant. So ist Eclipse deutlicher Favorit unter den IDEs. Ich hätte allerdings gedacht, dass Netbeans einen Schritt nach vorne macht aber es hat in punkte “häufig” zur letzten Erhebung sogar abgenommen.

Jetzt kommt der Chart für die Frameworks für Web-Anwendungen. Hier hat Spring immer noch die Nase vorn und das Resultiert wohl aus der allgemeinen JEE Entwicklung. Interessant ist auch, dass die Menge der Eigenentwicklungen deutlich vertreten ist. Das Ajax hier als Framework mit aufgeführt scheint mir ein wenig Fragwürdig allerdings ist schön zu erkennen, dass ohne Ajax wohl keine Web-Anwendung mehr entwickelt wird.

Im der Frage nach der Entwicklung von Rich Internet Applications (RIA) ist Ajax allerdings wieder richtig angesiedelt und im Gegensatz zur letzten Erhebung Ende letzten Jahres hat Ajax und Webstart an Häufigkeit zugenommen.

Diese sechs Charts sind nur ein kleiner Auszug aus dem Trendbarometer und zeigen die für diesen Blog wichtigsten Themen. Die hier aufgelisteten Themen können auch direkt mit dem Artikel über den letzten Trenbarometer verglichen werden.
Weitere Themen unter den Überschriften “Aktuelle Themen (SOA)”, “Open Source”, “Software-Entwicklungsprozess” und “Inovation und Weiterbildung” werden auch in dem Trendbarometer besprochen und auch sehr interessant. Der Trendbarometer kann kostenlos bei der Firma expeso kostenlos angefordert werden.

Das einleitende Zitat stammt übrigens aus dem Heise Forum zum entsprechenden Artikel über den Java Trendbarometer . Die Diskussionen in dem Form gehen von interessant bis amüsant und es lohnt sich daher einen Blick reinzuwerfen.

In dem Eclipse JEE Package muss man wie auch unter Ganymede erst das Subversive Plugin und anschließend einen Subversive Connector installieren. Man muss also zwei verschiedene Update Sites für die Installation ansprechen.

Subversive Plugin Installation

Das Subersive Plugin selbst steht unter der Eclipse Lizenz und ist somit direkt über die Eclipse Galielo Update Site http://download.eclipse.org/releases/galileo zu finden. Diese Update Site muss nicht neu hinzugefügt werden sondern ist schon im “Install new Software” Dialog (Hauptmenü->Help->Install new Software…) unter “Work with” bereits zu finden:

Wenn die Update Site ausgewählt wurde muss unter dem Punkt “Collaboration” der “Subversive SVN Team Provider (Incubation)” selektiert werden. Das ist das von Eclipse bereitgestelte Subversive Plugin:

Anschließend die Installation mit dem Button “Next” starten und den Dialog Angaben folgen.

Da noch eine weitere Installation der Subversive Connectors folgt muss Eclipse nicht dringend wie empfohlen neu gestartet werden.

Subversive Connector Installation

Nachdem das Subversive Plugin als Basis installiert wurde muss als Subversive Connector eine externe Bibliothek installiert werden. Dazu bietet Polarion wie auch schon zu Eclipse Ganymede verschiedene Connectoren an. Die benötigte Update Site URL ist http://community.polarion.com/projects/subversive/download/eclipse/2.0/galileo-site/. Diese muss im “Install new Software” Dialog (Hauptmenü->Help->Install new Software…) noch hinzugefügt werden.

Dazu die URL einfach in das “Work with” Eingabefeld kopieren und Enter drücken. Als Connectoren kann man entweder einen reinen Windows Connector (JavaHL) oder reinen Java Connector (SVNKit) verwenden. Welchen man verwenden möchte kann man selbst entscheiden. Es ist kein Problem alle angebotenen zu installieren da man diesen später noch konfigurieren kann:

Anschließend die Installation mit dem Button “Next” starten und den Dialog Angaben folgen. Eclipse nach der Installtion wie aufgefordert neu starten.

Subversive Konfiguration

Einmal installiert kann man im “Eclipse Installation Details” Dialog (Hauptmenü->Help->About Eclipse->Installation Details) die installierte Subversive Software aufgelistet sehen:

Welcher Subversive Connector verwendet werden soll kann in den Eclipse Preferences (Hauptmenü->Window->Preferences) unter Team->SVN im Reiter SVN Connector konfiguriert werden:

Einmal alles installiert und konfiguriert kann man in der SVN Perspektive nun einen SVN Repository einrichten und seine Projekte wieder mit dem SVN Repository synchronisieren.

Eclipse Galileo entspricht der Version 3.5 und bringt seinerseits auch wieder viele neue Dinge mit. Neben den bisher schon bekannten Projekte wie z.B. WebTools, Data Tools oder C/C++ Tools bringt Galileo fünf neue Projekte mit an den Start. Persönlich finde ich das Memory Analyzer Projekt (MAT) am interessantesten. Wer einen Einblick in MAT bekommen möchte sollte sich mal das dazugehörige Blog und auch das Webinar aus dem letzten Jahr ansehen.

Nebem dem MAT sind auch noch die PHP Developer Tools, eine Mylyn WikiText Unterstützung, eine Unterstützung um XSL Tooling um XSL zu bearbeiten und zu debuggen und Verbesserungen für die Business Intelligence Reporting Tools (BIRT) mit Galileo veröffentlicht worden (siehe auch Release Notes).

Das schöne an Veröffentlichungen von Eclipse und deren Plugins sind die “New and Noteworthy” Seiten auf denen die interessantesten Erneuerungen mit einem Screenshot erläutert werden. Für Eclipse Galileo ist die Seite entsprechend der vielen Erneuerungen auch wirklich lang. Im folgenden ein paar Erneuerungen die ich auf Anhieb ganz interessant fand:

• Platform – Compare Editor enhancements
  Wirklich brauchbare Erneuerungen wie Go to line oder Open Resource und Type sowie die Möglichkeit den Encoding Type auf jeder Seite des Editors neu zu setzen.
  
• Platform – Open Resource dialog allows choice of editor
  Man kann nun den Editor für die zu öffnende Datei direkt im Open Resource Dialog auswählen, falls gewünscht:
  
• Install/Update Changes
  Wie auch bei der letzten Version wurde einiges an dem Install und Update Management gearbeitet und verbessert. Um nur eine Sache herauszugreifen im folgenden der Screenshot des vereinfachten Hinzufügen neuer Update Sites:
  
• Java Editor – Constructor completion
  Der Content Assistent bietet nun die verfügbaren Konstruktoren der Klasse zur Auswahl an:
  
• Java Editor – Open Implementation hyperlink
  Ein Feature auf das wohl sämtliche Entwickler lange gewartet haben. Von einem Interface direkt in die Implementierung via Hyperlink springen sofern nur eine Implementierung vorhanden ist. Sind mehre da werden diese in der type hierarchy aufgelistet und man kann dann direkt wählen. Den Hyperlink erhält man indem man die Taste STRG gedrückt hält und mit der Maus über die Methode fährt. Der Dialog sieht dann wie folgt aus:
  
• Java Editor – Quick Fix to start Rename refactoring
  Möchte man eine Methode mit Quick Fix (Strg-1) umbennen besteht nun die Möglichkeit auch ein Refactoring über das Projekt zu starten:
  
• Java Editor – Formatter option to preserve user line breaks
  Eine der bisher sehr nervigen Details am Formatter war, dass ich meine selbstdefinierten Zeilenumbrüche nicht behalten durfte. Das soll jetzt vorbei sein:
  

  Und nach dem formatieren:

  
• Java Refactoring and Source Actions – Generate toString()
  Ein ziemlich cooles Feature ist die Unterstützung für die toString() Methode. Man erhält diesen Dialog aus dem Context Menü unter “Source->Generate toString()…” und dieser sieht wie folgt aus:
  
• Java Refactoring and Source Actions – Comparing identical values
  Wenn zwei gleiche Variablen verglichen werden wird das nun als Warning angegeben:
  
• Java Refactoring and Source Actions – Missing hashCode() method
  Der Compiler kann nun fehlende hashCode() Methoden finden auch wenn equals() schon vorhanden ist. Dieses Feature ist per Default ausgeschalten – einschalten kann man es unter “Preferences > Java > Compiler > Errors/Warnings in the Potential programming problems”.
  

Es gibt noch einige mehr Erweiterungen die man sich auf der “New and Noteworthy” Seite ansehen kann.

Neben den neuen Projekten werden natürlich auch wieder fertige Projekt Packages angeboten – darunter auch wieder das JEE Package mit den Web Tools und Data Tools:

Startet man das Eclipse Galileo JEE Package sieht man auch an der Welcome Page eine deutlichen Änderung:

Auf dieser Welcome Page sind unter anderem die sieben wichtigsten im JEE Package durch die Web Tools Platform mitgebrachten Unterstützungen aufgelistet: Web Services, Web, XML Tools, Server Tools, Java EE, JSF, JPA. Die Web Tools Platform 3.1, welche auch erst im Juni veröffentlicht wurde, hat auch einige Erneuerungen mitgebracht die unter “Eclipse Web Tools Platform 3.1 – New and Noteworthy” im Detail angesehen werden können.

Natürlich steht auch wieder das leidige Thema Plugin Update auf der Liste und diesmal haben die JBoss Tools schon ein wenig vorgearbeitet. Schon am Anfang des Monats wurde auf dem offiziellen Blog verkündet, dass man den JBoss Tools 3.1 Milestone 1 für Eclipse Galileo installieren und testen kann. Der Update Site Link für die Developer Version ist: http://download.jboss.org/jbosstools/updates/development.

Ich habe die JBoss Tools 3.1 M1 unter Eclipse Galileo installieren und auch ohne erkennbare Probleme verwenden können. In einem ersten Versuch hat das Umbennenen ohne Probleme funktioniert. Den Rename Dialog erhält man am einfachsten aus der Seam Component View heraus. Insgesamt ein wirklich sehr nützliches Feature!
In ersten Tests mit einem bestehenden Projekt lies sich insgesamt problemlos arbeiten. Im About Dialog von Eclipse werden die entsprechenden Plugins auch korrekt angezeigt:

Auch zu den JBoss Tools 3.1 M1 gibt es eine “News and Noteworthy” Seite auf der die einzelnen nennenswerten Erneuerungen zu finden sind. Ich möchte nur kurz eins hervorherben welche ich ziemlich praktisch finde und zwar ist das der “Rename Seam Component” Dialog, der verfügbar ist wenn man in einer Klasse die mit @Name annotiert ist, sich in der components.xml oder in der Seam components view befindet. Verwendet man diesen Dialog wird der Name auch in den xhtml Dateien gefunden und dort refactored:

Der Übergang von Eclipse 3.4 auf Eclipse 3.5 mit den JBoss Tools scheint also vorerst problemlos zu funktioniern (im Gegensatz zu dem Umstieg von 3.3 auf 3.4).

Somit wünsche ich viel Spass beim ausprobieren!

if(unknownObj instanceof Integer) {
  Integer myCastedIntObj = (Integer)unknownObj;
  // do sth with casted object
}

Um diesen “instance of” Code mit anschließendem Class Cast zu erstellen besteht in Eclipse die Möglichkeit einen Quickfix zu verwenden und so die Tipparbeit deutlich zu vereinfachen. Dazu einfach das Schlüsselwort instanceof anfangen zu schreiben und Strg-Space drücken. Es öffnet sich der QuickFix Panel mit Vorschlägen wobei instanceof direkt an erster Stelle steht:

Selektiert man diesen QuickFix und drückt Enter wird das Code Template im Editor erstellt um die restlichen notwendigen Angaben wie z.B. die Variable die geprüft oder die Klasse auf die gecastet werden soll. Was viele nicht wissen ist, dass wenn im Eclipse Editor ein blauer Rahmen um ein Wort steht kann man einfach mit Tab durch das Template navigieren:

Gibt man die Klasse an auf die geprüft werden soll wird sie auch direkt in der Zeile mit dem Cast eingesetzt:

Anschließend nur noch den Namen der neuen internen Variable anpassen und mit Enter den QuickFix und somit das Bearbeiten des Templates beenden. Der Cursor postiert sich nun direkt in die Zeile unter der Class cast Zeile und es kann somit direkt weitergearbeitet werden.

Man wird diesen QuickFix wahrscheinlich seltener brauchen aber wenn man ihn kennt und weiß wie sich Eclipse verhält kann man einen solchen instanceof Ausdruck binnen Sekunden und ohne große Mühe erstellen. Man sollte es also mal ausprobiert haben und wissen, dass es diese Unterstützung gibt.

Entity Bean mit JPA Annotationen	Dazugehöriges SQL Schema für diese Entity Bean

Meistens bringen die verschiedenen JPA Implementierungen eigene Tools mit. Verwendet man z.B. Hibernate kann man zum Beispiel die von Konsole Tools in Form eines ANT Tasks verwenden. Arbeitet man mit der Eclipse Ganymede IDE hat man mit dem Web Tools Subprojekt “Dali” (Dali JPA Tools) die Möglichkeit sich das DB Schema mit Hilfe eines Eclipse Dialogs generieren zu lassen. Ich habe schon mal bei der Vorstellung der JBoss Tools 3 Alpha Version darauf hingewiesen, dass das WTP Dali Projekt ab Version 3 unterstützt wird.

Nachdem ich diesen Artikel in der ausführlichen Version erstellt hatte kam mir dieser mehr doch sehr lang vor obwohl das Konfigurieren an sich relativ schnell geht. Dahier hier die wenigen Schritte in absoluter Kurzform:

• Projekt Facet “JPA Persistence” dem EJB Projekt hinzufügen (Projekt Properties)
• JPA Plattform und DB Verbindung konfigurieren (Projekt Properties)
• Im Cotextmenü auf dem EJB-Projekt “JPA-Tools->Generate DDL…” wählen
• Im DDL Generation Dialog das Zielverzeichnis, die Ausgabedatei und Hibernate Console- (konfigurierbar über die Hibernate Perspektive) oder DB-Konfiguration angeben. Dialog mit “Finish” beenden -> DDL Datei wird erstellt.

Im Folgenden wird anhand meines kleinen Java Schnipsel Projektes gezeigt wie das Datenbankschema, genauer gesagt die DDL (Data Definition Language) Datei, mit Eclipse generiert werden kann. Dieses Projekt verwendet Hibernate und somit werden aus den JBoss Tools Plugins das Hibernate Tools Eclipse Plugin benötigt. Nun sind die JBoss Tools 3.0.0 endlich offiziell Stable erschienen und da ist es an der Zeit dieses Feature mal auszuprobieren.

Im ersten Schritt sollte überprüft werden ob die Hibernate Tools installiert sind. Aus den JBoss Tools Eclipse Plugins wird für das Generieren der DDL Datei die Hibernate Tools benötigt. Für eine Installationsanleitung der JBoss Tools siehe hier.

Mein Beispielprojekt ist in der für Eclipse normalen JEE Projektstruktur erstellt worden (mit dem Seam Web Project Wizzard):

Hat man eine solche Projektstruktur muss man nun das JPA Project Facet hinzufügen. Dazu auf dem EJB Projekt aus dem Context Menü (recht Maustaste) “Properties” aufrufen. Im Properties Dialog “Project Facets” selektieren und dort das Facet “Java Persistence” auswählen:

Wenn das Facet “Java Persistence” selektiert wurde erscheint unten im gelben Hintergrund der Hinweis, dass weitere Konfigurationsmöglichkeiten bestehen (“Further configuration available”). Am einfachsten ist es diese Konfiguration direkt auszuwählen. Hat man die Einstellung mit “Apply” bestätigt einfach das Facet noch einmal deslektieren, Apply drücken und das Facet wieder selektieren.
In dem Dialog “Modify Facet Project -> JPA Facet” muss nun die verwendete JPA Platform und die DB Verbindung konfiguriert werden. Ich verwende Hibernate und habe meine MySQL Verbindung konfiguriert. Man kann direkt von diesem Dialog aus eine neue DB Verbindung konfigurieren, sofern man das noch nicht getan hat.

Die zwei weiteren dort möglichen Einstellungen habe ich bei mir auf “Use implementation provided by server Runtime” (Die Server Runtime kann in den Properties unter dem Punkt “Targeted Runtimes” konfiguriert werden – verwendet man keinen Server wie den JBoss kann man die JPA Jars auch direkt angeben) und “Discover annotated classes automatically” gesetzt. Anschließend den JPA Facet Dialog und anschließend den Properties Dialog mit “Ok” beenden.

Hat man allerdings den Properties Dialog schon vor den zusätzlichen JPA Einstellungen mit “Ok” beendet muss man noch einmal die Properties für das EJB Projekt aufrufen und kann dann aber den Menüpunkt “JPA” direkt selektieren und somit konfigurieren:

Nachdem die Java Persistence Project Facets dem JEE Projekt hinzugefügt wurden ist im Context Menü, sofern man dieses auf dem EJB Projekt aufruft, der Eintrag “JPA Tools” zu finden. Darin findet sich der Menüpunkt “Generate DDL”.

Erhält man nach dem Auswählen dieses Menüpunktes den Fehler “DDL Generation is not supported by the Generic Platform” hat man vergessen seinen JPA Platform (Hibernate, Toplink, ..) zu konfigurieren. Dazu einfach wieder in die EJB Projekt Properties und den Menüpunkt “JPA” selektieren und konfigurieren. Mehr Informantionen zu dieser Fehlermeldung auch hier.
Ist alles soweit korrekt konfiguriert öffnet sich der DDL Generation Dialog. Darin gibt man zuerst das Zielverzeichnis sowie den Namen der DDL Datei an. Die zweite wichtige Konfiguration ist der Hibernate Dialekt der verwendet werden soll. Dazu kann man entweder eine bereits durch die Hibernate Perspektive erstellte Hibernate Console Konfiguration verwenden und diese mit der Checkbox “Use Console Konfiguration” verwenden oder wie in meinem Fall die bereits konfigurierte Datenbankverbindung. Der Dialekt kann dabei automatisch erkannt werden (ich berichtete darüber) oder direkt angeben:

Ist alles korrekt konfiguriert wird durch den Button “Finish” das Generieren der DDL in der gewünschten Zieldatei gestartet. Das kann einen kleinen Moment dauern und anschließend ist diese Schemadatei auch unter der gewünschten Position (bei mir im EJB-Projekt im Ordner ejbModule) zu finden:

Gerade für die erste Entwicklungszeit und dem Erstellen der Entitäten ist diese einfach DDL Generierung sehr nützlich. Sieht man doch direkt was für Datenbanktypen aus den Java Attributen erstellt werden.

Alternativ kann man mit den Hibernate Tools über die Hibernate Perspektive das Schema auch direkt in der DB erstellen. Vor gut einem Jahr habe ich dazu einen kleinen Artikel erstellt.

Um das QuickFix Verhalten zu verdeutlichen habe ich den Namen der Klasse geändert, so dass dieser nicht mehr mit dem Namen der Datei (QuickFixTests.java) übereinstimmt. In Java ist das nicht erlaubt und somit bietet mir Eclipse mit dem QuickFix Dialog Lösungen an. Hier der Screenshot des Maus Hovers:

Hier der Screenshot des Klicks auf das Warning oder Error Icons links. Ist der Cursor in dieser Zeile kann man auch einfach Strg-1 drücken um diesen Dialog zu erhalten:

Einer der Features überhaupt ist das Generieren von Getter und Setter zu einem Attribut. So spart man sich deutlich Tipparbeit in dem man direkt nach dem Schreiben des Attributes Strg-1 drückt, “Generate getter and setter for ‘attributeName’” selektiert und Enter drückt:

Anschließend erscheint der Dialog für die Getter und Setter Konfiguration, welcher auch über das Context Menü “Source->Generate Getters and Setters..” geöffnet werden kann:

Vor allem die Einstellung an welche Position der Setter und Getter erstellt werden soll ist interessant: sollen die neuen Methoden an die erste oder letzte Stelle in der Klasse oder direkt hinter einer schon bestehenden Methode erstellt werden? Sind die Einstellungen erst einmal gesetzt worden werden sie für die nächste Generieren übernommen. So kann man anschließend die weiteren Getter und Setter ohne großes Konfigurieren schnell generieren.

Ist das Generieren durchgelaufen sind die Getter und Setter natürlich vorhanden:

Interessant an dieser Stelle zu erwähnen ist noch die farbliche Hervorhebung des Attributes. Hat man ein in der Eclipse Menüleiste den Button “Toggle Mark Occurrences” (Alt-Strg-O) eingeschaltet wie im folgenden Screenshot rot hervorgehoben zu sehen:

Dann die Verwendung des gerade mit dem Cursor selektierten Attributes farblich hervorgehoben. Dabei wird farblich zwischen lesenden und schreibenden Aktionen unterschieden. Dieses Verhalten ist im Screenshot davor mit den generierten Getter und Setter schön zu sehen.

Möchte man mit den JBoss Tools 3 arbeiten benötigt man Eclipse Ganymede. Es wird nicht empfohlen von Eclipse 3.3 auf Eclipse 3.4 via Update Manager zu wechseln. Viel praktischer ist es eine frische Eclipse Installation vorzunehmen und somit auch potentielle Fehlerquellen aus dem Weg zu gehen. Am einfachsten ist es wenn man die Eclipse 3.4 IDE for Java EE Developers herunterlädt. Auch hier gibt es mittlerweile das Release 2 Bundle, welches ca 170 MB groß ist.

Nachdem Eclipse heruntergeladen, entpackt und gestartet wurde einfach die JBoss Tools Update URL (http://download.jboss.org/jbosstools/updates/stable) im Eclipse Update Manager hinzufügen. Den Update Manager findet man im Hauptmenü unter Help->Software Updates. Dort den Reiter “Available Software” selektieren und rechts den Button “Add Site…” drücken:

Ist die Update Site hinzugefügt kann man nach dem Aufklappen alle angebotenen JBoss Tools sehen. Für meine Seam Entwicklung mit Hibernate, RichFaces auf dem JBoss AS installiere ich immer die folgende Tools (hervorgehobene Selektion):

Um die Installation fertigzustellen den Button “Install” drücken und den Anweisungen folgen.

Erstellt man über die JBoss Tools ein Seam Web Projekt sieht man schon die erste Erneuerung denn es wird jetzt auch Seam 2.1 direkt unterstützt, wie man auch bei der Konfiguration der Seam Runtime sehen kann:

Wer mit der Nightly Build oder 3.0.0 Alpha Version gearbeitet hat wird die neuen wirklich nützlichen Features wahrscheinlich schon gesehen und ausprobiert haben. Vor allem bei der Entwicklung von Facelets XHTML Seiten in Verbindung mit Seam Komponenten sind sehr schöne Features in die neue Version reingekommen. Ein paar davon, die ich persönlich absolut praktisch finde, sind im folgenden kurz aufgelistet.

Autocompletion:
Es werden alle mit @Name annotierten Seam Komponenten direkt im XHTML Editor gefunden und durch Autocomplete angeboten:

EL Warning:
Hat man eine Fehler in der Expression Language gemacht wie der typische “rechte-Klammer-fehlt” Fehler findet man diesen nun nicht mehr erst nach dem Deployment sondern direkt im Editor durch ein Warning:

Seam Komponenten und Links direkt aus dem Editor heraus öffnen:
Man kann nun direkt aus dem XHMTL Editor heraus durch halten von STRG und der Maus direkt in die Java Klassen der Seam Komponenten oder direkt in andere .xhtml Seiten springen:

Visueller Editor für die pages.xml:
Es gibt nun eine wirklich gute Unterstützung für die pages.xml. Darunter auch eine visuelle Ansicht für die Navigationsregeln, die in der pages.xml definiert werden:

Mehr Bilder zu den neuen Features findet man auch wie gewohnt im Kapitel “News and Noteworthy“.
Alles in allem ist es wirklich schön endlich eine funktionierende und offizielle Version der JBoss Tools für Eclipse Ganymede zu haben. Nun steht der Entwicklung von vielen schönen neuen Seam Projekten nichts mehr im Wege =).

Die offizielle Meldung für die JBoss Tools 3.0 findet man auch noch mal hier zum nachlesen.

Unit Tests sind vielen Entwicklern ein Begriff und in der Java Welt verbindet man diesen Begriff fast automatisch mit dem Testframework JUnit. Dabei steht als genereller Gedanke hinter Unit Tests einzelne kleine Teilbereiche (Units, Methoden, Funktionen) atomar und unabhängig von einer Umgebung und Abhängigkeiten zu testen. Man geht davon aus, dass wenn die einzelnen kleinen Teile eines Systems in Ihrerer Aufgabe funktionieren und diese korrekt tun das große Ganze auch Bestand hat. Dabei gelten nur die Zustände: Erfolg oder Fehler.

In diesem und folgenden Artikeln soll es um den JUnit Konkurrenten TestNG gehen. Das Testframework TestNG ist laut seinem Entwickler Cédric Beust aus der JUnit Frustration entstanden und das NG in TestNG bezieht sich auf Next Generation.

Wer diese Frustration nachlesen möchte kann dies hier und hier tun.

Nicht nur wegen dieser Aussage soll TestNG ein wenig näher begutachtet werden. Wer z.B. mit JBoss Seam arbeitet wird sehr schnell merken, dass Seam von Haus aus eine TestNG Unterstützung mitbringt. Auch andere Frameworks setzen auf TestNG. Aber auch ohne diese Frameworks bietet TestNG eine sehr gute Alternative zu dem schon genannten JUnit.

Das Ziel dieses ersten TestNG Artikels ist einfache TestNG Unit-Tests zu erstellen und aus Eclipse heraus ausführen zu können. In folgenden Artikeln wird es mehr in die Möglichkeiten von TestNG und in die Konfiguration von Tests und Testsuites gehen.

Um TestNG zu verwenden muss die aktuelle Version heruntergeladen werden. Zur Zeit ist die aktuellste Version 5.8 und kann hier direkt heruntergeladen werden.

Es besteht auch eine Eclipse Unterstützung für TestNG, die über eine Update Seite installiert werden kann. Dazu unter Eclipse 3.4 (Ganymede) über “Help->Software Updates…->Available Software Tab->Add Site…” klicken, die TestNG Update Site URL http://beust.com/eclipse angeben und mit “OK” bestätigen. Anschließend das neu hinzugefügte Element aufklappen, das Plugin TestNG selektieren und den Button “Install” drücken.

Bei der Installation den Anweisungen folgen. Es kam bei mir ab und an vor, dass bei der Bestätigung für die zu installierende Software nur ein leeres Fenster auftrat – da einfach mit “OK” weiter klicken.
Nach dem Neustart von Eclipse steht eine TestNG View zur Verfügung und kann geöffnet werden.

Um TestNG aus Eclipse heraus verwenden zu können müss die TestNG Bibliothek noch im Classpath referenziert werden. TestNG liefert zwei jars aus: eine für Java 1.4 (testng-5.8-jdk14.jar) und eine für Java 5 (testng-5.8-jdk15.jar). Beide liegen im heruntergeladenen TestNG.zip im Root Verzeichnis oder alternativ im TestNG Eclipse Plugin Ordner (eclipse\plugins\org.testng.eclipse_5.8.0.2\lib). In meinem Fall kopiere ich mir das testng-5.8-jdk15.jar in meinen im Projekt erstellten lib Ordner und gebe dieses im Projekt Classpath an (Rechte Maustaste auf den Projekt Ordner->Properties->Java Build Path).

Als Beispielprojekt bzw. Beispiel Source Code der getestet werden soll habe ich ein Java Projekt mit zwei Source Ordnern erstellt. Ich persönlich mag es lieber, wenn die Testklassen in einem getrennten Source Ordner liegen. So besteht bei mir der Source Ordner: src und test sowie ein normaler Ordner für die benötigten Java Bibliotheken lib. Unterhalb der zwei Source Ordern erstelle ich zweimal das gleiche Package. Anschließend in dem Ordner src die Klasse de.javathreads.util.Calc und in den Ordner test die Klasse de.javathreads.util.CalcTest. Nach getaner Arbeit sieht die Projektstruktur wie folgt aus:

Nun schauen wir uns den Source Code der zwei Klassen etwas genauer an. Die Klasse de.javathreads.util.Calc beinhaltete die einfachen Methoden add() und divide():

package de.javathreads.util;

public class Calc {

  public int add(int first, int second) {
    return fist + second;
  }

  public double divide(int first, int second) {
    if (second == 0) {
      throw new ArithmeticException();
    }
    return first / second;
  }
}

Um mit TestNG eine Methode zu definieren die den eigentlichen Unit-Test enthält wird diese mit der Annotation org.testng.annotations.Test versehen. Um abzuprüfen ob das Ergebnis dem erwarteten Ergebnis entspricht arbeitet TestNG mit Java Assertions und dem Schlüsselwort assert. Das sieht dann in meiner CalcTest Klasse, welche die Methode Calc.divide() testen soll, wie folgt aus:

package de.javathreads.util;

import org.testng.annotations.Test;

public class CalcTest {

  /**
   * Test für simples dividieren.
   */
  @Test
  public void divideSimple() {
    Calc c = new Calc();
    double sum = c.divide(4, 2);
    assert (sum == 2);
  }

  /**
   * Test für Division durch 0.
   */
  @Test
  public void divideByZero() {
    Calc c = new Calc();
    try {
      c.divide(4, 0);
    } catch (ArithmeticException ex) {
      assert (true);
      return;
    }
    assert (false);
  }
}

Bei einer Prüfung mit dem Schlüsselwort assert muss der Ausdruck immer true ergeben. Mehr zu Java Assertions kann auch in dem javathreads Artikel “Reservierte Schlüsselwörter in Java – Assertions” sowie im Java Blog Buch gefunden werden.

Durch das TestNG Eclipse Plugin ist ein Unit Test sehr einfach durch das Context-Menü direkt aus dem Package Explorer heraus zu starten. Dazu mit der rechten Maustaste direkt auf die Klasse klicken welche die mit @Test annotierten Methoden enthält und anschließend unterhalb des Menüpunkts “Run As” den Punkt “TestNG Test” anklicken:

Es ist auch möglich auf ein Package zu klicken und somit alle darin liegenden Testklassen zu starten.
Nach einem oder mehreren durchlaufenen Unit-Tests wird das Ergebnis in der TestNG View farblich hervorgehoben. Dabei wird farblich gezeigt ob generell alle Test positiv waren (grün) oder mindestens einer fehlgeschlagen ist (rot). Im folgenden ein Screenshot für den Fall das alle Tests positiv waren:

Ist mindestens ein Test fehlgeschlagen wird der Balken schön rot und man die fehlgeschlagene Methode erkennt man durch das rote Kreuz. Selektiert man diesen Test erhält man im rechten Fenster die Exception zu dem Fehler. Bei TestNG sind das immer java.lang.AssertionError, wie man im folgenden Screenshot sehen kann:

Mit einem Doppelklick auf die Methode gelangt man direkt in den Java Editor an die gewünschte Stelle der Testklasse. Es wäre nun auch möglich den Test im Debug Modus zu starten. Dazu anstatt “Run As” einfach den Test mit “Debug As” starten. Dabei natürlich nicht vergessen einen Breakpoint zu setzen ;).

In der Console können noch die Logausgaben und auch das Gesamtergebnis begutachtet werden. Treten Exceptions in der zu testenden Klasse auf sind diese auch in der Konsole sichtbar. Im folgenden die Konsolenausgabe des Positiven Tests:

Als letzte Information zu dieser kleinen Einführung noch der Hinweis, dass TestNG immer mit XML Konfigurationsdateien arbeitet. Der Vorteil wenn das TestNG Eclipse Plugin verwendet wird liegt darin, dass dieses Plugin die XML Datei generiert. Aktualisiert man im Package View das Projekt (Projekt selektieren und F5 drücken) erscheint die Datei temp-testng-customsuite.xml:

Schaut man in diese Konfigurationsdatei rein sieht man wie der einfachste Fall eines TestNG Tests vie XML konfiguriert werden kann. Die Testklasse wird direkt angegeben:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="JavaTestNGProject">
  <test verbose="2" name="de.javathreads.util.CalcTest" annotations="JDK">
    <classes>
      <class name="de.javathreads.util.CalcTest"/>
    </classes>
  </test>
</suite>

Man kann natürlich auch eine solche XML Konfigurationsdatei manuell erstellen und via Eclipse Kontextmenü als TestNG Test ausführen. Dazu legt man sie einfach mit im Test-Source Verzeichnis ab.

In diesem Artikel wurde gezeigt wie man TestNG in Eclipse einbindet und das Eclipse Plugin verwenden kann. Zudem wurde ein sehr einfacher Test geschrieben und ausgeführt. Grundsätzlich ist man nun also in der Lage Tests zu schreiben und diese auch auszuführen, was den ein oder anderen schon deutlich weiter bringen dürfte ;).
Im nächsten Artikel über TestNG wird mehr auf die Möglichkeiten mit TestNG eingegangen. Welche Annotationen gibt es und wie kann man sie einsetzen bzw. wo liegen die Vorteile.

Das Kapitel ist über 60 Seiten lang und behandelt die Themen “Perspektiven, Sichten, Editoren”, “Java Programme eingeben und bearbeiten”, “Suchen, Ersetzen und Refactoring”.

Alles drei sind Themen die man ständig während der Entwicklung benötigt. Vor allem zwischen den Perspektiven und Editoren springt man oft hin und her aber auch das Refactoring ist in Eclipse sehr ausgereift.

Scrapbook Pages

Ich weise auf dieses Probekapitel vor allem deswegen hin, weil es mir beim Durchblättern tatsächlich auch etwas Neues gebracht hat: die Scrapbook Pages (Seite 94). Bisher kannte ich die Möglichkeit der “Scrapbook Pages” in Eclipse nicht.

Der Autor Thomas Künneth beschreibt die Scrapbook Pages wie folgt:

Mit dessen Hilfe können Sie Java-Anweisungen eingeben und sofort ausführen. Ihnen steht hierbei sogar der Debugger zur Verfügung. Sie können beispielsweise problemlos Variablen inspizieren.

Es besteht also die Möglichkeit Java Code “eben mal schnell” zu testen, sogar zu debuggen.
Eine solche Scrapbook Page erstellt man durch das Hauptmenü: “File->New->Other…->Java->Java Run/Debug->Scrapbook Page”

Anschließend muss man noch ein Verzeichnis in der die Scrapbook Page Datei abgelegt werden soll selektieren und einen Namen vergeben. Die Endung einer solchen Scrapbook Page Datei ist .jpage und wird automatisch angehängt.

Auf der Scrapbook Page kann man beliebige Java Ausdrücke platzieren und hat die Möglichkeit diese zu prüfen (inspect), anzuzeigen (display) oder auszuführen (execute). Eine solche Aktion führt man aus indem man den entsprechenden Ausdruck selektiert und aus dem Kontextmenü die Aktion wählt:

Wählt man die Möglichkeit “display” so wird der Ausdruck ausgewertet und das Ergebnis direkt in das Scrapbook geschrieben. Für das Random Beispiel sieht es wie folgt aus:

Möchte man mehr Details wie in einem Debug Zustand zu einem Objekt erfahren bietet sich das Kommando “inspect” an. Man bekommt alle für diese Objekt zum Zeitpunkt der Instanziierung zugänglichen Attribute zu sehen:

Das letzte Kommando ist “execute“. Mit diesem ist es möglich einen Ausdruck oder ganze Blöcke auszuführen und das Ergebnis zu sehen. Damit kann man z.B. Schleifen oder Abfragen schnell testen. Das Ergebnis wird in der Console ausgegeben:

Java Klassen in einer Scrapbook Page müssen allerdings voll qualifiziert angegeben werden. So reicht es nicht einfach nur aus “new Random()” zu schreiben sondern man muss vollen Packagepfad mit angeben: “new java.util.Random()“. Weil aber das Scrapbook Page Editor Auto Completion unterstützt sollte das weniger ein Problem sein:

Hat man eine bestimmte Umgebung in der man immer wieder mit dieser Scrapbook Page arbeitet bietet es sich an die Imports generell zu konfigurieren. Die Imports kann durch das Kontextmenü auf den Editor unter “Set Imports” konfigurieren. Es erscheint ein Dialog indem man einzelne Klassen aber auch ganze Packages angeben kann:

Somit erspart man sich die voll qualifizierten langen Klassennamen.

Als kleinen Nachteil könnte man das zwingende Erstellen solcher Scrapbook Pages Dateien notieren. Es muss eine solche Datei im Projekt erstellt werden damit man Java Code Schnipsel in dieser Umgebung ausführen kann. Der Vorteil der sich aber daraus ergibt ist, dass dadurch auch alle für dieses Projekt im Classpath verfügbaren Bibliotheken verfügbar sind.

Insgesamt sind Scrapbook Pages wohl ein bisher sehr unbekanntes aber durchaus nützliches Feature.