Von Software-Messies und Jar-File-Schlampen

Manche Menschen können sich von nichts trennen. Sie müssen alles aufheben, es könnte ja noch gebraucht werden. Am Ende haben sie keinen Überblick mehr über die gehorteten Dinge und verlieren sich in ihnen. Die Fachwelt spricht von einer Desorganisationsproblematik, in schweren Fällen vom Vermüllungssyndrom. Umgangssprachlich bezeichnen wir solche Leute als „Messies“; sie haben „schwerwiegende Defizite in der Fähigkeit, die eigene Wohnung ordentlich zu halten und die Alltagsaufgaben zu organisieren“ [1].

Zu den Alltagsaufgaben eines IT-Architekten gehört es, Abhängigkeiten seines Softwaresystems bewusst zu planen. Hierzu zählen Beziehungen zwischen eigenen Bausteinen (zum Beispiel Subsystemen und Komponenten), zu Fremdsystemen, und insbesondere auch Abhängigkeiten zu Drittprodukten. In Java-Projekten ist es Folklore, für Funktionalität, die nicht die eigentliche Kernaufgabe berührt, auf Fremdbibliotheken zurückzugreifen. Der Open-Source-Bereich bietet hier viel Verlockendes, und hat der klassischen Entscheidung „Make or Buy“ eine dritte Alternative hinzugefügt: „Take“.

Bei Reviews von Softwaresystemen frage ich gern, welche Abhängigkeiten zu Fremdbibliotheken vorliegen. „Och, eigentlich nicht so viele – nur Spring und Hibernate“ war einmal die Antwort. Was übersehen wurde: Diese Lösungen bringen selbst reichlich Potenzial für weitere Abhängigkeiten mit. Und die Verwendung der bequemen Spring-Integrationen verschleiert schnell, was nicht noch alles benötigt wird. Im konkreten Fall waren dies zum Beispiel auch AspectJ, Quartz, und Einiges mehr. Im Projekt hatte man keinerlei Überblick darüber.

Nun sollte man meinen, dass die Abhängigkeiten spätestens dann klarer werden, wenn die Lösung irgendwo durch Dritte in Betrieb genommen werden muss. Denn beim Deployment müssen ja alle benötigten Jar-Files vorgelegt werden – ansonsten gibt es in der Produktion hässliche ClassNotFoundExceptions. Das obige Projekt behalf sich einfach, indem es alle Bibliotheken, die (Zitat) „bei Spring und Hibernate so mit dabei sind“, mit in seine Lieferung packte, und ersparte sich so den Aufwand, herauszufinden, welche es genau benötigte. Das waren dann gefühlte 100 Stück. Bei vielen war unbekannt, wozu sie gut sind. serp-1.13.1.jar? „Wir wissen nicht, was das macht, und ob wir es wirklich brauchen. Aber wir lassen es mal lieber drin – wer weiß?“ – Messies in Entwicklungsprojekten?

In den letzten Kolumnen habe ich bereits einige Sichten auf Architektur beleuchtet. Welche physikalischen Informationseinheiten (Jar-Files, DLLs …) im Rahmen des Entwicklungsprozesses erstellt bzw. benötigt werden, welche Komponenten sie manifestieren, und wie sie für den Betrieb zu verteilen sind, ist ein weiterer Aspekt. Er wird in Architekturdokumentationen in der so genannten Verteilungssicht [2] beschrieben. In der UML gibt es einen eigenen Diagrammtyp dafür: das „Deployment Diagram“ (deutsch Verteilungsdiagramm). Als Modellelemente kommen hier Knoten (z.B. Hardware, Laufzeitumgebungen) und Artefakte wie etwa Anwendungsarchive (EAR-Files etc.) zum Einsatz. Diese werden geeignet verbunden, etwa mit Dependency- oder Deployment-Beziehungen. Zentral ist aber nicht die Form der Dokumentation, sondern dass der Aspekt nicht vernachlässigt wird, und zum Beispiel die Struktur der Abhängigkeiten überhaupt geplant und verstanden wird.

Denn Jar-Files sind kein Schüttgut. Lieblos in den lib-Ordnern der Deployment-Artefakte oder gleich in der Zielumgebung abgeworfen bergen Sie Gefahren. Stellen Sie sich nur vor, in einer Fremdbibliothek wird ein Fehler entdeckt, und Sie müssen auf eine höhere Version umstellen, um ihn zu beheben! Was für Auswirkungen wird das haben? Was, wenn die Wiederverwendbarkeit eines Moduls bewertet werden soll? Was benötigt es, um zu laufen? Sind die Bibliotheken vielleicht nur zum Kompilieren erforderlich, oder nur für die Ausführung der Tests, oder zur Laufzeit? Laufen die Sachen auch unter JDK 1.4 oder Servlet 2.3? Und was, wenn der Auftraggeber nach Ursprung oder gar Lizenz der in der Lieferung enthaltenen Open-Source-Perlen fragt? Wussten Sie zum Beispiel, dass die Anzahl unterschiedlicher Lizenzen, unter denen die „Beimischungen“ eines Spring-Framework-Downloads stehen, zweistellig ist? Wenn die Unordnung der eigenen Lösung ein gewisses Maß überschritten hat, muss plötzlich Softwarearchäologie betrieben werden. Und man wundert sich, wie Lösungen in wenigen Monaten „historisch wachsen“ können.

Besonders unglücklich wird die Situation, wenn die Jar-Files aus unterschiedlichen Quellen stammen und so ungeschickt geschnitten sind, dass verschiedene Fassungen der gleichen Klasse in den Archiven enthalten sind. Wenn am Ende die Reihenfolge der Bibliotheken im Klassenpfad entscheidet, ob die Anwendung die richtige Version verwendet, sind wir dem Fegefeuer der Jar-File-Hölle nahe.

Natürlich ist in den letzten Jahren in vielen Java-Projekten Ordnung eingekehrt. Werkzeuge wie Maven und Ivy machen Abhängigkeiten zum Zeitpunkt des Builds explizit – die Projektbeschreibungen (im Falle von Maven etwa die Datei pom.xml) liefern Hinweise, was zur Laufzeit verfügbar sein muss. Mit geeigneten Werkzeugen kann man früh Abhängigkeiten visualisieren, und so gegen eine Vermüllung ankämpfen – in tragischen Fällen betrifft diese die POM-Files selbst.

Ein weiterer Lichtstrahl am Messie-Horizont: OSGi-Bundles liefern in Form von Metadaten einen regelrechten Beipackzettel mit, was sie in welcher Version benötigen und anbieten. Auf OSGi-Basis erstellte Lösungen sind nicht automatisch so sauber, dass man sich drin spiegeln kann. Aber aufgeräumter sind sie in der Regel schon. Nicht jedes Projekt braucht die Dynamik, die OSGi bietet. Abhängigkeiten explizit zu machen, ist aber in jedem Fall ein wichtiger Beitrag zu einer sauberen Architektur.

Links & Literatur

[1] „Messie-Syndrom“ bei Wikipedia, http://de.wikipedia.org/wiki/Messie
[2]  Gernot Starke, “Effektive Software-Architekturen”, Hanser Fachbuch, 5. Auflage 2011

Zuerst erschienen hier:
Stefan Zörner: Kolumne Architekturen dokumentieren.
“Von Software-Messies und Jar-File-Schüttgut”, Java Magazin, 03/2009, 2 Seiten, S. 56
(mit freundlicher Genehmigung)