Whitespace Handling in FreshMarker (2)
Im ersten Beitrag zum Whitespace Handling wurde eine einfache Implementierung vorgestellt, die überflüssige Whitespaces entfernt. In diesem Beitrag soll die Implementierung verbessert werden.
Thoughts on agile software development
Im ersten Beitrag zum Whitespace Handling wurde eine einfache Implementierung vorgestellt, die überflüssige Whitespaces entfernt. In diesem Beitrag soll die Implementierung verbessert werden.
Bei der Entwicklung des EnumConverterProcessor wurde der Quellcode mit Hilfe der Template-Engine FreeMarker geschrieben. Daher war die Neugierde groß, ob der Quellcode auch mit FreshMarker erfolgreich erzeugt werden kann. Dabei zeigte sich jedoch, das der Umgang mit Whitespaces in der neuen Template-Engine noch nicht ganz ausgereift war. Genaugenommen produzierte die Template-Engine zu viele Leerzeichen und Zeilenumbrüche.
Im vorherigen Beitrag wurde ein Annotation Processor vorgestellt, mit dem AttributeConverter für Enum Klassen automatisch generiert werden können. Kaum war dieser fertig gestellt, bahnten sich schon die ersten Änderungen an. Die WithEnumConverter Annotation erhält die neuen Attribute ordinal, nullKeyForbidden, exceptionIfMissing und verliert das Attribut representation
In diesem Beitrag finden zwei meiner Steckenpferde hier im Blog zusammen. Es sind die Annotation Processors und die Enums. Beide gemeinsam können ein schon lange bestehendes Problem der Enums auf recht elegante Weise lösen.
Die Klasse MessageFormat ist ein Urgestein der Java API und schon seit der Version 1.1 mit an Bord. Die Klasse ist ein nützlicher Helfer, wurde aber in den letzten Versionen der API stark vernachlässigt. Nicht nur in der Java API wurde sie längere Zeit nicht beachtet, auch manches Projekt hat diese Klasse unnötigerweise gemieden.
Nichts ist ärgerlicher bei der Verbesserung von Legacy Software als die Abhängigkeit von Klassen, die sich modernen Sprach Konstrukten verweigern. Eine besondere Gruppe dabei sind all die Klassen, die sich zieren vom Interface AutoClosable zu erben. Diese Klassen sind durch veraltete Abhängigkeiten in das eigene Projekt geflossen und diese Abhängigkeiten sind aus mannigfaltigen Gründen dem Zugriff des Entwicklers entzogen.
Dieser und weitere Beiträge werden sich mit der Template-Engine FreshMarker beschäftigen. Das Besondere an dieser Template-Engine ist, dass sie noch nicht existiert. Die Beiträge werden, parallel zur Entwicklung der Template-Engine, technische Entscheidungen und verwendete Konzepte beleuchten.
Das automatisierte Erstellen von Software hat eine lange Tradition. GNU Make erblickte 1976 das Licht der Welt, Apache Ant im Jahr 2000, Apache Maven 2002 und Gradle 2007. Dies sind nur die bekanntesten Tools zur Build Automatisierung, viele weitere sind bis heute entstanden und es werden wohl noch einige erfunden werden. Alle diese Tools haben ihre Vorzüge und Nachteile und je nach Projekt und Technologie bietet sich eine Tool besonders an. Häufig kommt ein Entwicklungsteam mit den Maven Standard Plugins aus. Hin und wieder gibt es aber den Moment, wo ein zusätzliches Plugin wünschenswert wäre.
Häufig bleiben interessante Erweiterungen für Anwendungen liegen, weil der Aufwand für die Ablauflogik zu hoch erscheint. Eine solche Erweiterung ist die Automatisierte Stammbaumfreigabe für den Ancestor Rest Service aus dem Beitrag REST in Peace.
Kürzlich las ich bei Martin Fowler einen interessanten Artikel zu einem Design-Pattern von Pete Hodgson. Dazu schossen mir sogleich zwei Ideen durch den Kopf. Zuerst die Frage, warum erst jetzt diese Pattern formuliert wird und gleich darauf der Gedanke, eine meiner Klassen schleunigst umzuschreiben.