Was tun, wenn das Framework stirbt?

Jedes größere Open-Source-Projekt basiert auf Open Source Libraries und Frameworks. Und so, wie sich Betriebssysteme, Tools und Applikationen weiterentwickeln (müssen), ist dies auch bei den zugrundeliegenden Libraries und Frameworks der Fall. Doch kann es natürlich auch einmal passieren, dass die Weiterentwicklung einer bestimmten Bibliothek oder eines Framework eingestellt wird.

Dies ist zunächst kein Problem, wenn die aktuellste Version stabil ist und keine oder nur unwesentliche Bugs aufweist. Doch die technische Entwicklung bleibt nicht stehen und eine Software-Komponente, die nicht weiter entwickelt wird, veraltet mit der Zeit. Und während sich dieser Umstand bei Closed-Source-Software elegant im nicht zugänglichen Quellcode verstecken lässt, tritt er bei Open-Source-Software für jedermann offen zutage!

Daher muss das Entwicklerteam irgendwann in den sauren Apfel beißen und das sterbende Framework durch ein lebendes, modernes Produkt ersetzen. Im Idealfall wirkt sich solch ein Wechsel nicht nur positiv auf die Architektur der Software aus, sondern macht mittelfristig die Weiterentwicklung der Software sogar einfacher und schneller.

Für Zeitpunkt und Art des Umstiegs gibt es jedoch kein Patentrezept. Stattdessen im folgenden ein Beispiel aus der Praxis:

Für unser Open-Source-Projekt OpenEMM nutzen wir unter anderem das Struts-Framework für die Umsetzung des MVC-Entwurfsmusters im Rahmen einer Web-Applikation. Das Struts-Framework war im Jahr 2000 das erste Open-Source-MVC-Framework, wird jedoch seit zwei Jahren nicht mehr nennenswert weiterentwickelt (die letzte 1.3.9-Beta ist deutlich über ein Jahr alt).

Der Struts-Gründer Craig McClanahan (derzeit bei SUN beschäftigt) hat 2004 mit JavaServer Faces (JSF) ein neues Framework gestartet, das mittlerweile als echter Java-Standard sogar im Wettbewerb zu Struts steht. Darüber hinaus sind im Laufe der Jahre mit Spring MVC, Tapestry und WebWork weitere MVC-Frameworks für Web-Applikationen entstanden, die Struts Konkurrenz machen, und teilweise moderner sind.

Und dann gibt es da natürlich noch die - eigentlich naheliegende - Alternative Struts2. Kurioserweise baut Struts2 allerdings nicht auf Struts(1) auf, sondern auf WebWork2, so dass Struts2 nicht abwärtskompatibel zu Struts ist. Damit erfordert der Wechsel von Struts auf Struts2 genauso ein Refactoring des vorhandenen Quellcodes, wie der Wechsel zu jedem anderen Web-MVC-Framework.

In unserem Fall war nach reiflicher Überlegung trotzdem Struts2 die beste Wahl als Nachfolger für Struts, denn Struts2 bietet gegenüber Struts eine ganze Reihe von Vorteilen:

1. Es ist viel weniger Infrastruktur-Code erforderlich, weil
   
   
   
   1. die Devise "Convention over Configuration" gilt
   
   
   2. keine FormBeans-Klassen erforderlich sind (die Setter und Getter sind direkt in den Actions und selbst das lässt sich vermeiden)
   
   
   3. zahlreiche vordefinierte und -implementierte Interceptors (für Exception, I18n, Logging, etc.) und Validatoren vorhanden sind
   
   
   4. die Struts2-Tags HTML-Code mit generieren können (der sich über Themes der Tag-Templates beeinflussen lässt)
   
   
2. Das Struts2-Framework kümmert sich automatisch um den Datentransfer (inkl. Typ-Konvertierung) zwischen Model und View


3. Struts2 lässt sich über existierende Plugins für Struts, Spring, Tiles, etc. konfigurationsfrei erweitern


4. Struts2 (*.action) lässt sich parallel zu Struts (*.do) einsetzen und erlaubt damit die Migration Schritt für Schritt


5. Die AJAX-Integration ist/wird durch AJAX-Plugins mit Tag-Extensions und AJAX-Templates verbessert

Andererseits sind diese Vorteile für uns nicht so spektakulär, dass sie den Zusatzaufwand für einen sofortigen Umstieg rechtfertigen. Außerdem sind die Struts2-Vorteile - wie bei jedem neuen Framework - nur nutzbar, wenn man sich im Vorfeld intensiv mit dessen Architektur und Funktionsumfang auseinandersetzt, um die neuen Features auch tatsächlich nutzen zu können.

Daher haben wir beschlossen, die Migration von Struts auf Struts2 ganz in Ruhe anzugehen, indem wir jeweils die Teilbereiche, die ohnehin grundlegend überarbeitet werden müssen, im Rahmen des Refactoring auf Struts2 migrieren. Das "alte" Struts ist zwar inzwischen zu einer Sackgasse geworden, aber es handelt sich dabei um ein solides und äußerst stabiles Framework, das bei uns zuverlässig seinen Dienst verrichtet ohne unangenehm aufzufallen. Daher besteht beim Umstieg überhaupt kein Grund zur Eile.