Was machen eigentlich Groovy und Grails?

In den letzten Jahren ist es ruhiger um Groovy und Grails geworden. Die Gründe dafür sind vielfältig. Einerseits sind beide Projekte mittlerweile über 10 Jahre alt. Die Welt ist aber nicht stehen geblieben und andere interessante Sprachen und Frameworks haben die Aufmerksamkeit in Fachmagazinen oder auf Konferenzen auf sich gelenkt. Hinzu kam eine scheinbar fehlende Mainstream-Tauglichkeit im Falle von Groovy (Stichwort dynamische Typisierung), wodurch ein Großteil der Java-Entwickler letztlich abgeschreckt wurde. Die vielen Vorteile von Groovy und Grails gingen da leider unter.

Vor zwei Jahren gab es zudem einen größeren Einschnitt, bei dem das Fortbestehen beider Projekte sogar auf der Kippe stand. Die bisherige Mutter Pivotal hatte im Januar 2015 angekündigt, sowohl Groovy als auch Grails nicht mehr zu unterstützen. Viele haben sich damals gefragt, wie und ob es überhaupt weitergeht. Dem Team rund um Groovy wurden zudem durch die Schließung der Codehaus-Plattform weitere Steine in den Weg gelegt. Aber dank einer starken Community und einer gewissen Reife haben sich beide Projekte durch diese Probleme nicht entmutigen lassen und konnten letztlich sogar gestärkt aus der Situation hervorgehen.

Leider haben die Turbulenzen und die daraus entstandenen Unsicherheiten die neuen Funktionen der Releases 2.4 (Groovy) bzw. 3.x (Grails) ziemlich in den Hintergrund gedrängt. Dabei sind Groovy und Grails schon längst reif für den produktiven Einsatz. Bei Groovy werden zwar seit etwa zwei Jahren kleinere Brötchen gebacken, aber das ist auf den nun fehlenden Hauptsponsor zurückzuführen. Die Opensource Community hat das allerdings gut aufgefangen und entwickelt zumindest in kleinen Schritten weiter. Und auch wenn es natürlich immer etwas zu verbessern gibt, so wartet man bei Groovy aktuell nicht auf dringend benötigte Features. In diesem und weiteren Beiträgen wollen wir nun den aktuellen Stand analysieren, natürlich auch einen Blick auf die wichtigsten und interessantesten Neuerungen der vergangenen Releases werfen und einen Ausblick in die Zukunft wagen.

Am Beispiel der Gardner Hypekurve kann man erkennen, dass es vielen Technologien so ergeht. Nach dem Gipfel der Erwartungen in den Anfangsjahren folgt meist ein Tal der Ernüchterung, wenn die breite Masse merkt, dass man nicht alle Vorteile haben kann, ohne auch die einen oder anderen Konsequenzen in Kauf zu nehmen. Typischerweise erholen sich die Projekte schließlich, wenn die ernsthaft Interessierten den Pfad der Erleuchtung beschreiten und sich so die Technologie auf einem gewissen Niveau (der Produktivität) etabliert. Bei Groovy ist es schwer, diese Kurve mit Jahreszahlen zu versehen. Aber darauf kommt es auch nicht wirklich an. Der tendenzielle Verlauf lässt sich auf jeden Fall nachvollziehen.

Aktuell bekommen wir mit dem Thema Microservices wieder ein schönes Beispiel für diese These geliefert. Obwohl der Ansatz bereits einige Jahre alt war, begann mit dem Artikel von Martin Fowler und James Lewis Anfang 2014 (technologischer Auslöser) ein regelrechter Hype. Aber bereits ein Jahr später machte sich Ernüchterung breit. Auch bei Microservices gibt es keinen Free Lunch und die Umsetzung passt nicht zu jeder Unternehmensform (Conway’s Law). Zudem sind die Nachteile nicht trivial und müssen irgendwie behandelt werden, insbesondere die verteilte Natur der Services und die daraus resultierenden Folgen. Trotzdem werden sich Microservices für eine ausgewählte Benutzergruppe als adäquater Architektur-Stil durchsetzen. Überprüfen können wir diese These aber frühestens in den nächsten Monaten und Jahren. Immerhin gibt es bereits einige Firmen, die diesen Stil sehr erfolgreich einsetzen (Netflix, otto.de). Übrigens, wer jetzt schon auf den Microservice-Zug aufspringen möchte, findet mit Grails ein bereits ausgereiftes Framework für die Umsetzung vor.

Dass es um Groovy ruhiger geworden ist, kann man auch gut an ReGina nachvollziehen. Es handelt sich hier nicht um die Schwiegermutter eines Groovy-Core-Entwicklers. Vielmehr kam im Januar 2007 (kurz nach Groovy 1.0) ein Buch heraus, das bis heute die Bibel der Groovy-Enthusiasten ist: Groovy in Action. Im Zeitalter der maximal 140 Zeichen bei Twitter musste eine Abkürzung gefunden werden, was zu “GinA” führte. Zwei Jahre später hatten sich die Autoren überlegt, die Neuerungen aus zwei Minor-Releases in eine zweite Auflage einfließen zu lassen. Anfangs war man optimistisch, aber erst 6 Jahre und viele Twitter-Nachrichten später (Suche nach #regina #groovy bzw. #groovylang), konnte man im Juli 2015 diese zweite Auflage (“ReGinA”) in den Händen halten. Oberflächlich betrachtet, schienen die Autoren nicht mehr genug Enthusiasmus an den Tag zu legen. Dem war aber nicht so. Vielmehr war Groovy als moderne, sich lange Zeit schnell weiterentwickelnde Sprache einer der Hauptgründe für die lange Verzögerung. Durch die hohe Häufigkeit von neuen Releases ergab sich ständig neuer Input, den man auch noch im Buch verarbeiten wollte. Darum kam für ReGina das “Pivotal-Debakel” Anfang 2015 sogar gerade Recht, ergab sich dadurch doch endlich mal eine Zwangspause. Dank des Early-Access-Programms des Verlags konnte man übrigens bereits lange eine vorläufige Fassung “abonnieren” und bekam so regelmäßig die Aktualisierungen frei Haus geliefert.

Um die Gegenwart zu verstehen, lohnt immer ein Blick auf die Geschichte. Darum werden wir in einem Folgebeitrag zunächst in die Vergangenheit schauen, dann natürlich den Ist-Zustand analysieren und noch einen Ausblick wagen. Diejenigen, die Groovy und Grails vor Jahren aus den Augen verloren haben, sollten auf jeden Fall mal wieder einen Blick riskieren. Es hat sich in den vergangenen Jahren einiges getan. Detailliertere Informationen finden sich in zwei Artikeln der Java Aktuell.

Short URL for this post: https://wp.me/p4nxik-2PO
This entry was posted in Groovy and Grails and tagged , , , , , . Bookmark the permalink.

One Response to Was machen eigentlich Groovy und Grails?

  1. Danke für das Update über Groovy und Grails!

Leave a Reply