Lotus Notes / Domino Sonstiges > Java und .NET mit Notes/Domino

Neue Serie: Eclipse plug-ins im Praxis Test

(1/2) > >>

flaite:
So, nachdem jetzt die Apperitiv-Schlürfer von der Computer-Woche Eclipse plug-ins hypen, hab ich mir überlegt, dass ich mir da einfach ein bischen mehr Mühe geben könnte.

Ich werde also verschiedene Plug-ins und Erweiterungen auf die Tauglichkeit hin überprüfen. Der Maßstab ist meine Interpretation von "Praxis-Einsatz".  ;D

Disclaimer: A fool with a tool still is a fool (oder so ähnlich).
Der obige Satz ist imho sehr wahr. Eclipse-Plug-Ins sind kein silver-bullet, mit dem man plötzlich wer weiss wie produktiv wird. Sie können aber den Sachkundigen bei der Arbeit unterstützen. Jemand, der zu faul und uninteressiert ist, um sich die zugrunde liegenden Mechanismen verständlich zu machen, wird gerade mit plug-ins mitten in Lala-Land enden.

Ich werde in der Folge ein paar Eclipse plug-ins testen und hier berichten. 

1. Omondo plug-in für UML

Ich beginne mit dem Omondo UML plug-in, dass nun angeblich tatsächlich Reverse-Engineering Fähigkeiten hat.

a) Installation: verlief reibungslos:
- Ich hatte die entsprechenden Versionen (waren sogar noch Zusatzplug-ins vom Web-Tools Projekt sowie ein plug-in für Springframework-Entwicklung in der Eclipse Version, wo ich das reininstalliert habe, drin.
- Eclipse Menü: Help/About Eclipse SDK/plug-in Details meldete: KEINE FEHLER  O0

b) Dokumentation: Ein 517 Seiten langsames PDF mit vielen Screenshots scheint die Hauptdokumentation zu sein.

c) Tests
i. Reverse Engineering (dh: automatisches Generieren von UML-Diagrammen aus meinem Code):

Rechte Maustaste auf ein bestehendes Projekt. UML/Reverse Engineering.
Dialog 1-> Source Folder auswählen (ich hab eigene SourceFolder für Config-Dateien und für Unit-Tests. Hake nur den reinen Source Code an. (Auswahl ist sinnvoll).

Dann wurde ich darüber informiert, dass Bytecode Analysis nur mit Osmodo Pro geht. Ich weiss gar nicht was das ist, aber egal.

Es folgt ein längerer Prozess (dauerte genau so lange wie Zug 30 und Zug 31 des gleichzeitig auf KGS übertragenen Go Europameisterschaftsmatches Shikshina-Shilt (also ca 15 Minuten, lol).

Ich bekomme nun mehrere Diagramme, die ziemlich schick aussehen.
Zunächst hat das gute Stück mir ein Eclipse Package Dependency Diagramm generiert.
(s. Attachment Nr 1).
Erinnert mich schmerzhaft daran, dass meine neue Strategie nicht mehr so viele verschiedene Packages zu benutzen vermutlich ein bischen übertrieben ist.

Egal. Hier ist das gute Stück. Ich kapiere nicht ganz, warum es kein implements-Pfeil von de.aja.fussi.dao.ibatis nach de.aja.fussi.dao gibt, weil eigentlich jede Klasse in de.aja.fussi.dao.ibatis ein Interface aus de.aja.fussi.dao implementiert. Aber egal.

Daneben verspricht der Kontextmenü-Punkt "open" eine Menge wesentlich interessanterer Diagramme, die mir dieses Gratis-Tool generiert hat:
- Class Inheritance Explorer
- Class Dependency Explorer
- Class Association Explorer

Ich hab bisher keine Zeile Dokumentation gelesen und find das sehr cool.
Ich hab mal den Class Dependency Explorer geöffnet. Auch der scheint <<implements>> nicht darzustellen. Trotzdem bringt mir das ein mehr an Übersicht in diesem Projekt.
Nicht optimal. Aber so bekomme ich Eigenschaften und Methoden von verschiedenen meiner Klassen sowie ihre Assoziationen angezeigt, ohne dass ich mich sonderlich anstrengen mußte.
(s. Attachment 2).
Ausserdem hat alles funktioniert (d.h. keine Errors zwischendurch).

PRAKTISCHER NUTZEN:
Ich brauchte nichts zu tun, um mir Class Diagramme von meinem Code zu erstellen. Nur einen Knopf drücken und es war da. Class-Diagramme sind natürlich nicht alles. Sequenz Diagramme verschaffen in vielen Situationen mehr Übersicht in einem multi-geschichteten Java-Projekt.
Was bringen mir also diese Class-Diagramme.
Nun ich habe eine bessere Übersicht.
Das funktioniert ganz ähnlich wie ein Lotus-Script Klassenposter.
Ich habe jetzt alle mehr oder weniger intelligenten Properties und Methoden meiner selbstgedrehten Klassen in einem Dokument als Übersicht.
Das hilft schon, um mir eine Überblick zu verschaffen, bevor ich den nächsten Use Case implementieren will.

d) Aktuelles Fazit: Dieses Tool wird erstmal nicht de-installiert und es hat sich dafür qualifiziert, dass ich mir mal ein bischen das Doku-PDF durchlese.

Falls ich mal Zeit habe kann ich versuchen mit dem Osmondo Plug-In das Domain Modell eines Mini-Projekts in UML zu modellieren. Und dann daraus Code zu generieren.

e) Funstuff:
1. Das gleichzeitig installierte Spring Nature Plug-In meldet sich jetzt immer mit dem Osmonod Splash-Screen. Das ist aber alles. Kurios, scary, bisher aber nicht bedrohlich.  ;D

f) Was fehlt:
1. Automatisch generierte Sequenzdiagramme wären wirklich hilfreich.

Axel

Thomator:
Hi Axel,

danke für den Überblick, so was ist schon mal interessant.

Du hast völlig recht, Sequenzdiagramme wären das wirklich Interessante.
So ein Klassendiagramm ist ja nicht schlecht, aber ich finde, das hier auch der Package-Explorer in Zusammenarbeit mit der Generierung von Javadoc gute Dienste leistet.

Aber wie gesagt, als Überblick wohl nicht so schlecht. Sollte sich noch irgendwo in dem Plugin ein Mini-Schalter für das Generieren von Sequenz-Diagrammen finden, dann bin ich einer der Ersten, die dat Dingen downloaden.

Thomas

flaite:
Hier ist übrigens eine weitere Eclipse-plugin Liste in deutsch:
http://www.java-tutor.com/java/eclipse/plugin/eclipse-plugins.html

Ich habe jetzt XMLBuddy heruntergeladen und bin schwer enttäuscht. Vielleicht kann mich jemand anders von diesem Teil überzeugen. Mir hilfts leider überhaupt nichts. Ich dachte ich hätte da einen vernünftigen xml-Editor mit Baumstruktur für die zahlreichen xml Dateien meines Projekts (spring, ibatis, log4j). Ist aber nicht. Angeblich ist in WebToolsPlatform ein guter xml-Editor drin. Krieg da aber auch keine xml Dateien reingeladen. Vermutlich mache ich was falsch. Wäre dankbar, wenn jemand mal einen Hinweis geben könnte.

Gut ist codeSugar. (http://codesugar.sourceforge.net/). Das ist ein sehr kleines plug-in. Es hilft um die ziemlich nervigen
# equals()
# toString()
# hashCode()
Methoden zu erstellen. Ausserdem clone(). Aber clone() benutze ich nicht.
Alle diese Methoden sind Bestandteil von java.lang.Object. Da alle Java-Klassen letztlich von java.lang.Object erben, haben alle Java-Klassen diese Methoden.

Diese Methoden werden gebraucht, um Objekte von einer Klasse vergleichen zu können.
Z.B. habe ich beschlossen, dass 2 meiner StockDescription Objekte gleich sind, wenn der shortname gleich sind.
HashCode hängt damit zusammen. Alles hervorragend in der einschlägigen Literatur dargestellt.
Dies ist alles ein bischen kompliziert, wird aber oft benötigt.

Die Methoden werden nach Auswahl im CodeSugar Menüpunkt automatisch erzeugt:

--- Code: --- /**
* Returns <code>true</code> if this <code>StockDescr</code> is the same as the o argument.
*
*/
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null) {
return false;
}
if (o.getClass() != getClass()) {
return false;
}
StockDescr castedObj = (StockDescr) o;
return ((this.id == null ? castedObj.id == null : this.id
.equals(castedObj.id))
&& (this.longName == null
? castedObj.longName == null
: this.longName.equals(castedObj.longName))
&& (this.shortName == null
? castedObj.shortName == null
: this.shortName.equals(castedObj.shortName))
&& (this.version == castedObj.version)
&& (this.price == null ? castedObj.price == null : this.price
.equals(castedObj.price)) && (this.created == null
? castedObj.created == null
: this.created.equals(castedObj.created)));
}


--- Ende Code ---
Die geht vermutlich auf alle public getter. Ich muss mir das dann nur noch zurechtschneiden (brauch nur Vergleich auf longname und shortname).

--- Code: --- public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null) {
return false;
}
if (o.getClass() != getClass()) {
return false;
}
StockDescr castedObj = (StockDescr) o;
return ((this.longName == null
? castedObj.longName == null
: this.longName.equals(castedObj.longName))
&& (this.shortName == null
? castedObj.shortName == null
: this.shortName.equals(castedObj.shortName))
);
}

--- Ende Code ---

Bei mit equals zusammengehörigen hashCode gehe ich ähnlich vor.

--- Code: --- /**
* Override hashCode.
*
* @return the Objects hashcode.
*/
public int hashCode() {
int hashCode = 1;

hashCode = 31 * hashCode + (longName == null ? 0 : longName.hashCode());
hashCode = 31
* hashCode
+ (shortName == null ? 0 : shortName.hashCode());

return hashCode;
}

--- Ende Code ---

Dieser ziemlich oft vorkommende code sieht wirklich nicht nach Spaß aus. Das macht dann das plug-in. Die Hintergründe muß man natürlich zumindest auf User-Ebene verstehen (hat was mit Collections zu tun).

ToString sollte man auch immer erzeugen. Wenn man sich mal ein Objekt im Logfile oder per System.out.println (schlechte Idee) anzeigen will, kann man hier bestimmen was dort angezeigt wird. Das erledigt auch das Plug-In.
Wie üblich werden die Eigenschaften dort aufgelistet:

--- Code: --- public String toString() {
StringBuffer buffer = new StringBuffer();
buffer.append("[StockDescr:");
buffer.append(" id: ");
buffer.append(id);
buffer.append(" longName: ");
buffer.append(longName);
buffer.append(" shortName: ");
buffer.append(shortName);
buffer.append(" version: ");
buffer.append(version);
buffer.append(" price: ");
buffer.append(price);
buffer.append(" created: ");
buffer.append(created);
buffer.append("]");
return buffer.toString();
}


--- Ende Code ---

Ich Idiot hab das immer von Hand gemacht.

CodeSugar ist klein und sehr praktisch.

Axel

flaite:
Heute hat endlich Log4E seinen Weg in den Praxistest gefunden.
http://log4e.jayefem.de/index.php/Main_Page
Warum?
Ich war in dem FormulaToLotusScript Projekt zu faul log4j statements in den Code einzubauen.
Die sehen so aus, wie Logging Statements eben aussehen (Aufruf an Logger irgendwo im Code). Die nachträglich einzufügen ist sehr, sehr langweilig.

Nun habe ich dieses Plug-In (die pro-Version, ist aber sehr billig und hat 45 Tage Testperiode) in mein Eclipse runtergeladen, konfiguriert und gestartet (mit Doku lesen hat das 30 Minuten gedauert). 
Ergebnis:
Pro Klasse wird ein statisches logger Objekt erzeugt. Und zwar exakt so wie ich das auch machen würde:

--- Code: --- /**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(TRoot.class);

--- Ende Code ---

Die Log-Statements werden im gesamten Projekt automatisch generiert. Zu Beginn von jeder Methode gibt es jetzt einen Loger-Call (und auch bei fast jedem return statement).

Sieht bei einem Anfang der Methode so aus:

--- Code: ---void addVariable(String variableName, TVariable tVariable) {
  if (logger.isDebugEnabled()) {
logger
.debug("addVariable(String=" + variableName + ", TVariable=" + tVariable + ") - start"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
}

[...] my stuff [...]
if (logger.isDebugEnabled()) {
logger
.debug("addVariable(String=" + variableName + ", TVariable=" + tVariable + ") - end"); //$NON-NLS-1$ //$NON-NLS-2$ //$NON-NLS-3$
}
}

--- Ende Code ---

Und das ist besser als ich das je gemacht habe. Und zwar richtig nach best practices. Das if (logger.isDebugEnabled()) bringt Performancegewinne, wenn in der Log4j Konfigurationsdatei für den Log-Level debug kein logging stattfinden soll.

Es gibt eine Menge Einstellungen. (Über Eclipse-Menü Windows/Preferences). Man kann auch Alternative Logging Frameworks verwenden (z.B. jdk-logging).
Bei der code Generierung wird angezeigt, wo Änderungen durchgeführt werden (Pro Version).

Wenn es mehrere return statements gibt, die nicht unbedingt am Ende der Methode stehen, dann kann das Teil kein Log-Statement generieren und sagt das auch und v.a. auch wo. Logging für return statements ist eh ein bischen umstritten und in den Einstellungen des plug-ins nur optional wählbar.

Logging wird praktisch in jedem Java Projekt verwendet und das Tool hilft bei dem langweiligen Einfügen der benötigten Statements.
Natürlich werde ich aus bestimmten Methoden logging wieder entfernen. Bei get und set Methoden wurden schon von vorneherein keine generiert. Aber das ist deutlich weniger Arbeit als den langweiligen code selbst zu schreiben.

Die Webseite des Plug-Ins stellt die benötigten Infos sehr übersichtlich dar.

Dieses Plug-in ist soweit ich weiss von einem deutschen Studenten geschrieben worden und der Mann scheint wirklich zu wissen was er tut.  8)


Ein Problem ist echt, dass dieses Ding einfach den Source Code eindeutig zu viel mit Log-Statements ausstückt. Man muß das glaub ich ein bischen selektiver anwenden. Kann man auch. Aber es gibt eindeutig ein zu viel an Log Statements wie  ich jetzt lerne.

Gruß Axel   

flaite:
Nächster Praxistest: QuickREx von Bastian Bergerhoff. Dieses plug-in für das Erstellen von Regular Expressions erhält sehr hohe Ratings auf plug-in central und ist umsonst.

Navigation

[0] Themen-Index

[#] Nächste Seite