Für meinen Arbeitgeber, die Zimory GmbH, habe ich einen Prozessor für die @ToString Annotation implementiert.

equals und hashCode

Was können jetzt die nächsten Schritte sein? Als Erstes fällt natürlich ein ähnlicher Mechanismus für equals und hashCode ein. Hierfür gibt es aber schon hervorragende Unterstützung in den IDEs. Ebenfalls muss für dieses beiden Methoden der Sourcecode angepasst werden. Grund: equals und hashCode können gravierdende Auswirkungen auf ein System haben. Deswegen muss in den Javadocs dokumentiert sein, dass das die beiden Methoden überschrieben wurden. Das Problem könnte mit Annotationen und dem Annotation Processing Tool umgesetzt werden.

Loggen

Mit einer einheitlichen toString() lässt sich aber auch das Loggen stärker vereinfachen und vereinheitlichen. Loggen ist ein klassisches Cross-Cutting Concern. Es hat im Code fachlich selten etwas zu suchen. Dadurch, dass es gemacht wird, bläht es den Code wiederum unfachlich auf. Ergebniss: irgendwann sieht der Entwickler vor lauter Log-Anweisungen das fachliche nicht mehr.

Eine @Log Annotation kann da weiter helfen. Sie kann auf Konstruktoren, Methoden und lokalen Variablen angewendet werden. Bei Konstruktoren und Methoden erzeugt ein Prozessor beim Ein- bzw. Austritt Logmeldungen. Bei Eintrittmeldungen können die eventuell übergebenen Parameter ausgegeben werden und/oder der aktuelle Zustand des Objektes. Bei Austrittsmeldungen eventuell der Rückgabewert und auch der aktuelle Zustand des Objektes.

Lokale Variablen

Bei lokalen Variablen kann es Sinn machen, wenn die Methoden grösser sind. Eigentlich bin ich ein Freund von Composed method and SLAP. Deswegen muss loggen von lokalen Variablen nicht wirklich sein. Dennoch kann es machmal sinnvoll sein.

Aktuelle Grenzen

Java setzt hier allerdings Grenzen. Zwar können lokale Variablen annotiert werden, die Information geht aber beim Compilieren verloren. Sie geht auch verloren, wenn die RetentionPolicy auf CLASS gesetzt ist (default). Der Grund bei Java 5 war, dass keine Struktur im Classfile-Format für lokale Annotationen definiert war. In Java 6 können lokale Annotationen theoretisch verwendet werden, allerdings wurde die Funktionaliät im Compiler ausgeschaltet. Der Compiler des JSR 308 (downalod ) Projektes erzeugt die nötigen Informationen. Mal sehen ob der Compiler es in Java 7 schafft. Bis es soweit ist, schiebe ich das Problem beiseite.

Wieso nicht den Quellcode modifizieren?

Macht es Sinn den Quellcode zu parsen und den benötgen Log-Code für lokale Annotationen einzuweben? Soetwas kann gemacht werden. Allerdings unterscheidet sich dann der erzeugte Quellcode wahrscheinlich hinsichtlich Zeilenposition. Dies wiederum ist unschön bei Stacktraces, wenn Entwickler Zeilennummern bekommen. Dies haben keine sinnvolle Aussagekraft mehr und sind wertlos. Da das Logging zusätzlich für die Fehlersuche herangezogen wird, kann eine Quellcodemodifikation hier kontraproduktiv wirken. Aus diesem Grund ziehe ich sie nicht weiter in Betracht.

Ausblick

Im nächsten Eintrag diskutiere ich dann, wie die Annotationen für ein vereinfachtes Logging aussehen müssen. Ebenfalls wird diskutiert, welche Logging-Frameworks wie unterstützt werden und welche Probleme es dabei gibt.