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:
/**
* 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)));
}
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))
);
}
Bei mit equals zusammengehörigen hashCode gehe ich ähnlich vor.
/**
* 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;
}
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:
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();
}
Ich Idiot hab das immer von Hand gemacht.
CodeSugar ist klein und sehr praktisch.
Axel
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:
/**
* Logger for this class
*/
private static final Logger logger = Logger.getLogger(TRoot.class);
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:
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$
}
}
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