D: 4,

90 EU

R A:

5,60

EUR

CH: 9

,80 C

HF B

enel

ux: 5

,80 E

UR

ISSN

2191

-697

7

Java

aktu

ell Javaaktuell

03-2016 | Herbst | www. ijug.eu

Praxis. Wissen. Networking. Das Magazin für EntwicklerAus der Community — für die Community

419

1978

3049

0303

iJUGVerbund

Container-ArchitekturVerteilte Java-Anwen-dungen mit Docker

MicroservicesSchnell und einfach implementieren

Java-Web-AnwendungenFallstricke bei dersicheren Entwicklung

46 |

Open Source

ren Konsequenzen in Kauf zu nehmen. Typi-scherweise erholt sich die Kurve schließlich, wenn die ernsthaft Interessierten den Pfad der Erleuchtung beschreiten und sich die Technologie auf einem gewissen Niveau (der Produktivität) etabliert. Bei Groovy ist es schwer, diesen Verlauf mit Jahreszahlen zu versehen. Aber darauf kommt es auch nicht wirklich an. Die Tendenz lässt sich auf jeden Fall nachvollziehen.

Aktuell bekommen wir mit dem Thema „Microservices“ wieder ein schönes Bei-spiel für einen solchen Verlauf geliefert. Obwohl der Ansatz bereits einige Jahre alt war, begann mit dem Artikel von Martin Fowler und James Lewis Anfang 2014 ein regelrechter Hype (technologischer Auslö-ser). Aber bereits ein Jahr später machte sich Ernüchterung breit. Auch bei Micro-services gibt es keinen „Free Lunch“ und die Umsetzung passt nicht zu jeder Unter-nehmensform („Conway‘s Law“). Zudem sind die Nachteile nicht trivial und müssen irgendwie behandelt werden, insbesonde-re die verteilte Natur der Services und die daraus resultierenden Folgen. Trotzdem werden sich Microservices für ausgewähl-te Szenarien als adäquater Architektur-Stil durchsetzen. Überprüfen können wir diese These allerdings frühestens in ein paar Mo-naten, wenn nicht sogar Jahren. Übrigens, wer jetzt schon auf den Microservices-Zug aufspringen möchte, findet mit Grails ein bereits vollkommenes Framework für die Umsetzung vor.

Dass es um Groovy ruhiger geworden ist, kann man auch gut an ReGina sehen. Es han-

delt 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 überlegten sich die Autoren, die Neu-erungen aus zwei Minor-Releases in eine zweite Auflage einfließen zu lassen. Anfangs war man optimistisch, aber erst sechs Jahre und viele Twitter-Nachrichten später (Suche nach „#regina“, „#groovy“ beziehungsweise „#groovylang“) konnte man im Juli 2015 die-se zweite Auflage (Wortspiel: „ReGinA“) in den Händen halten.

Oberflächlich betrachtet, schienen die Autoren nicht mehr genug Enthusiasmus an den Tag zu legen. Aber weit gefehlt, vielmehr war Groovy als moderne, sich stetig weiterentwickelnde Sprache der ei-gentliche Grund für die lange Verzögerung. Durch die hohe Häufigkeit der Releases ergab sich ständig neuer Input, den man auch noch im Buch verarbeiten wollte. Man kämpfte also tapfer dagegen an, dass das Buch bei der Veröffentlichung nicht schon wieder veraltet war. Das Pivotal-Debakel Anfang 2015 kam den Autoren um Dierk König somit gerade recht, ergab sich da-durch doch endlich mal eine Zwangspause. Dank des Early-Access-Programms des Verlags konnte man zudem bereits lange eine vorläufige Fassung kaufen und bekam außerdem die Aktualisierungen regelmä-ßig frei Haus geliefert.

Der bisherige Herausgeber 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 durch die Schließung der Codehaus-Plattform zudem weitere Steine in den Weg gelegt. Dank einer starken Com-munity und einer gewissen Reife haben sich beide Projekte durch diese Probleme aber nicht entmutigen lassen und konnten sogar gestärkt aus der Situation hervorgehen.

Ruhig gewordenIn den vergangenen Jahren war es bereits deutlich ruhiger um Groovy und Grails ge-worden. Die Gründe dafür sind vielfältig. Einerseits sind beide Projekte mittlerweile mehr als zehn Jahre alt. Die Welt ist jedoch nicht stehen geblieben und andere interes-sante Sprachen und Frameworks haben die Aufmerksamkeit in Fachmagazinen oder auf Konferenzen auf sich gezogen. Hinzu kam eine scheinbar fehlende Mainstream-Tauglichkeit im Falle von Groovy (Stichwort: „dynamische Typisierung“), wodurch ein Großteil der Java-Entwickler unnötigerwei-se abgeschreckt wurde. Die vielen Vorteile von Groovy und Grails gingen da zuletzt lei-der unter.

Am Beispiel der Gardner-Hype-Kurve [1] kann man erkennen, dass es vielen Techno-logien so ergeht. Nach dem Gipfel der Er-wartungen in den Anfangsjahren folgt meist das Tal der Ernüchterung, wenn die breite Masse merkt, dass man nicht alle Vorteile haben kann, ohne auch die einen oder ande-

Groovy und Grails – quo vadis?Falk Sippach, OIO Orientation in Objects GmbH

Das Jahr 2015 begann turbulent für die beiden bekanntesten Projekte des Groovy-Universums. Die daraus entstandenen Unsicherheiten haben die neuen Funktionen der Releases 2.4 (Groovy) beziehungsweise 3.0 (Grails) ziemlich in den Hintergrund gedrängt. Dabei sind die Projekte lebendiger denn je und vor allem

schon längst reif für den produktiven Einsatz. Der Artikel analysiert den aktuellen Stand und wagt einen Ausblick in die Zukunft. In der nächsten Ausgabe folgt in einem zweiten Teil ein Blick auf die wichtigsten und interessantesten Neuerungen der vergangenen Releases.

| 47

www.ijug.euiii

iii iiiiii

Java aktuell 2-2016

HistorieEin Blick in die Geschichte zeigt, dass beide Projekte immer eng verbunden waren. In den Jahren 2003 respektive 2005 erblick-ten sie das Licht der Welt. Während sich bei Groovy die beiden maßgeblichen Initiatoren James Strachan und Bob McWhirter relativ schnell wieder zurückzogen, sind bei Grails die Gründer bis heute aktiv. Und auch bei Groovy fanden sich rasch neue Mitstreiter, die auch heute noch die Geschicke des Pro-jekts mitbestimmen.

Es wurde früh versucht, die Open-Source- Entwicklung über eine Firma (G2One) abzu-sichern, die sich wiederum mit Schulungen und Beratungsdienstleistungen finanzieren sollte. SpringSource, die Firma hinter dem Spring-Framework, übernahm aber schon kurz darauf G2One und damit Groovy und Grails in sein Open-Source-Portfolio. Wenig später wurde SpringSource dann Teil der Fir-ma VMware, die vor vier Jahren seine Open-Source-Entwicklungsabteilung in die Firma Pivotal ausgründete. Groovy und Grails haben also schon eine bewegte Geschichte hinter sich. Trotz aller Probleme und Widerstände konnten über all die Jahre immerhin mehrere Entwickler in Vollzeit an den Projekten arbei-ten. Jochen Theodorou hat die Geschehnisse aus seiner Sicht in einem nicht unkritischen Blog-Beitrag zusammengefasst [2].

Cedric Champeau hat in seinem Blog-Post „Who is Groovy?“ [3] die Geschichte aus einem anderen Blickwinkel betrachtet und anhand der Commits im Sourcecode-Repo-sitory nachvollzogen. Interessanterweise ist der fleißigste Entwickler, Paul King, gar nicht von Pivotal bezahlt worden − wiederum ein Zeichen für eine starke Community.

Beide Projekte entwickelten sich ständig weiter und insbesondere Grails wurde für Groovy der Innovationstreiber. Auch nach den Versionen 1.0 Ende 2006 beziehungs-weise 2008 kam es jährlich mindestens zu Minor-Releases und damit zu stetigen Ver-besserungen und natürlich auch jeder Men-ge neuer Funktionen.

Jähes EndeAnfang des Jahres 2015 kam nun der gra-vierende Einschnitt. Das Management von Pivotal suchte Kosten-Einsparpotenzial, man wollte sich auf die Kern-Kompetenzen (Cloud, Virtualisierung) konzentrieren. Dabei gerieten Groovy und Grails auf die Streich-liste, möglicherweise als Alibi aus Erman-gelung an anderen Alternativen. Vermutlich dürfte sich die Einsparung dieser sechs Ge-

hälter im Gesamtbudget kaum bemerkbar gemacht haben. Stattdessen hat man nun den Einfluss über Groovy und Grails verlo-ren, obwohl beide Projekte mittlerweile stark in der Spring(-Boot)-Welt verankert sind.

Groovy 2.4 und Grails 3.0 sind die letzten Major-Releases unter dem Sponsorship von Pivotal: „The decision … is part of Pivotal’s larger strategy to concentrate resources on … its growing traction in Platform-as-a-Ser-vice, Data, and Agile development … Pivotal has determined that the time is right to let further development … be led by other in-terested parties … who can best serve the goals ...“ [4]

Im Nachhinein betrachtet war der Zeit-punkt aber gar nicht schlecht gewählt. Im-merhin waren beide Projekte mittlerweile sehr ausgereift und haben seit Langem ei-nen festen Platz in der Open-Source-Welt eingenommen. Pivotal hatte außerdem eine Gnadenfrist von etwa drei Monaten zuge-standen. Die bereits angekündigten Relea-ses konnten so noch fertiggestellt werden. Für die bereits gekündigten Entwickler trotzdem keine leichte Zeit, da man neben-her nach einem anderen Sponsor oder einer neuen Arbeitsstelle suchen musste.

Wechsel zu ApacheIm Fall von Groovy verschärfte sich die Si-tuation letztlich noch. Der bisherige Infra-struktur-Anbieter Codehaus (Mailinglisten, Jira, Homepage etc.) musste sich der erdrü-ckenden Marktmacht von GitHub beugen und schaltete seine Systeme im Frühjahr 2015 ab. Auch wenn sich das schon längere Zeit angekündigt und man bereits Vorkeh-rungen getroffen hatte, diese Ereignisse fielen einfach unglücklich zusammen. Als Alternative wurde sehr ausführlich über den Anschluss an eine Open Source Foundation debattiert. Apache, Eclipse und Software Freedom Conservancy standen zur Auswahl [5]. Nach Abwägen der Vor- und Nachteile entschied man sich für die Apache Software Foundation. Mit der Aufnahme in den dorti-gen Inkubator mussten allerdings bestimm-te Anforderungen und Konventionen erfüllt werden. Das bedeutete neben dem Umzug der Infrastruktur (Issue Tracker, Code-Repo, Mailinglisten) auch Umstrukturierungen und Anpassungen an den Prozessen und am Projekt selbst.

Im Sommer konnten mit 2.4.4 und 2.4.5 zwar schon erste kleinere Bugfix-Releases unter der neuen Schirmherrschaft heraus-

gebracht werden, wirklich neue Funktionali-tät gab es aber seit 2.4 verständlicherweise nicht mehr. Immerhin ist mittlerweile wieder ein Großteil der ursprünglichen Committer an Bord. Auch da gibt es bei Apache gewisse Prozesse und Formalitäten, die es einzuhal-ten galt. Ende 2015 standen die Aussichten bereits gut, den Inkubator bald verlassen zu können. Als vollwertiges Apache-Projekt wird Groovy vermutlich nochmal mehr Auf-merksamkeit bekommen. Die steigenden Download-Zahlen im Jahr 2015 deuten schon darauf hin. Der Wechsel zu Apache hat dem Projekt also definitiv gutgetan.

Grails zu OCIDas Grails-Team, das bis kurz vor dem Ende der Zeit bei Pivotal hart an dem großen 3.0er-Release-Sprung arbeitete, gönnte sich zunächst einige Wochen der Ruhe. Aber bereits im Mai konnte mit OCI Inc. ein neu-er Hauptsponsor präsentiert werden, der direkt zwei der Haupt-Entwickler auf seine Lohnliste gesetzt hatte. Zudem verstärkte OCI seine Bemühungen im zweiten Halbjahr und stellte weitere Grails-Committer an. Man ist also sehr stark an einer Weiterent-wicklung interessiert und versucht, haupt-sächlich über Beratungsdienstleistungen und Projektgeschäft mit Grails die Ausgaben zu finanzieren.

Auch wenn sich für die Projekte letztlich alles zum Guten gewendet hat, so haben die Umstrukturierungen auch menschli-che Schicksale betroffen. Natürlich sind mittlerweile alle untergekommen. Aber ein Teil musste sich umorientieren. Von den ursprünglich sechs Pivotal-Angestell-ten können nur Graeme Rocher und Jeff Scott Brown weiter Vollzeit an ihrem Pro-jekt (Grails) entwickeln. Cedric Champeau (Groovy) und Lari Hotari (Grails) sind zu Gradle gewechselt und bleiben so immer-hin dem Groovy-Universum treu. Ihre Zeit für Groovy beziehungsweise Grails wird sich jedoch aufgrund der großen Aufgaben bei Gradle in Grenzen halten. Der ehemali-ge Groovy-Projektleiter Guillaume Laforge wird auch weiterhin als Botschafter und nun Apache PMC Chair zur Verfügung ste-hen, er hat sich beruflich aber mittlerweile der Firma Restlet zugewandt. Die läng ste Aus- und Bedenkzeit hatte sich Jochen Theodorou genommen. Seit Kurzem arbei-tet er nun bei der Schweizer Firma Canoo , die sich in den vergangenen Jahren im Um-feld von Groovy und Grails bereits einen Namen gemacht hat.

48 |

Open Source

Im zweiten Teil dieses Artikels werden wir einen genaueren Blick auf die Eigen-schaften und Neuerungen der letzten Groo-vy- und Grails-Versionen werfen. Für die Eiligen und die Entscheider wollen wir an dieser Stelle aber schon mal ein Fazit ziehen und den Ausblick in die Zukunft wagen.

AusblickNach den politischen Querelen waren viele zunächst verunsichert. Aber beide Projekte sind definitiv noch nicht reif für den Frame-work-Friedhof. Vielmehr sind sie gestärkt aus den Geschehnissen hervorgegangen, dank der bereits stabilen Codebasis und der großen Community. Dazu passt auch die Aussage von Guillaume Laforge: „Here to stay. Independence. Community above all.“

Dem Einsatz von Groovy und Grails steht also auch in Zukunft nichts im Wege. Aber wie bei allem ist es sinnvoll, die Stärken und Schwächen abschätzen zu können und entsprechend für die Einsatz-Szenarien abzuwägen. Man hat immer eine Wahl und sollte ganz bewusst entscheiden. Groovy eignet sich beispielsweise für Skripte, das Schreiben von Tests, die Verwendung als DSLs, Zugriffe über eine Admin-Konsole in Enterprise-Systemen und natürlich auch im Zusammenhang mit Grails, stellvertretend für viele andere Bibliotheken/Frameworks aus dem Groovy-Ökosystem.

Grails wurde immer als reines Web-Framework abgestempelt. Allerdings soll-te man es nicht unterschätzen, es deckt schließlich den ganzen Bereich von der Persistenz bis zum Frontend ab und bietet durch seine Modularität viel Flexibilität. Man hat immer die Möglichkeit, auf bestehende Plug-ins zurückzugreifen oder eigene zu entwickeln. Grails eignet sich von jeher auch gut für das Prototyping, weil man in kurzer Zeit sehr viel erreicht. Firmen sollen schon Ausschreibungen gewonnen haben, weil sich der Kunde die Umsetzung aufgrund des Prototyps bereits sehr gut vorstellen konnte.

Als klassische Web-Anwendung emp-fehlen sich aus eigenen, etwas leidvollen Erfahrungen aber eher kleine Intranet-Anwendungen. Es gibt jedoch auch diverse Erfolgsgeschichten zu Umsetzungen von größeren Projekten mit Grails. Eine wichtige Voraussetzung dafür ist, dass man ein Team zusammenhat, das die Stärken und Schwä-chen von Groovy und Grails kennt und damit umgehen kann. Alle müssen am gleichen Strang ziehen, was bei einem Mischmasch

aus Groovy-affinen und klassischen Java-Entwicklern meist nicht der Fall ist.

Mit Grails kann man beispielsweise ge-nauso gut auch ein schlankes REST-Back-end implementieren, auf dem dann SPA/RIA-JavaScript-Clients aufsetzen. Und da Grails seit Version 3.0 auf Spring Boot auf-setzt, eignet es sich auch wunderbar für die Entwicklung der verschiedenen Ausprägun-gen von Microservices.

RoadmapsEin Blick auf die aktuellen Roadmaps zeigt, dass sich Groovy und Grails erstmals in ihrer langen Geschichte auseinanderbewegen. Während man bei Grails mittlerweile wieder sehr positiv und mit vielen Ideen in die Zu-kunft blickt, versucht man sich beim Groo-vy-Projekt nach der Aufnahme bei Apache zunächst mal zu sammeln. Hier macht sich bemerkbar, dass das Grails-Team zum größ-ten Teil zusammenbleiben konnte und wei-terhin von einer Firma finanziert wird, die aus wirtschaftlichen Gründen auch an einer raschen Weiterentwicklung interessiert ist. Am Groovy-Projekt hingegen arbeitet der-zeit niemand Vollzeit, die drei bisherigen Core-Entwickler sind bei unterschiedlichen neuen Arbeitgebern untergekommen.

Zum Glück ist der Bedarf bei Groovy aber auch nicht ganz so hoch. In den letzten Jah-ren ist bereits eine mächtige JVM-Sprache entstanden und es fehlen keine wichtigen Show Stopper. Die noch im Jahr 2014 ausge-gebenen größeren Ziele, die Neukonzeption des Meta Object Protocol (MOP) basierend auf Invoke Dynamic und die Re-Implemen-tierung der Sprachgrammatik in Antlr v4, wurden nach dem Abschied von Pivotal zunächst auf Eis gelegt. Ganz typisch Open Source wird natürlich trotzdem weiter-entwickelt. Auf der Developer-Mailingliste herrscht reger Betrieb und für die kommen-de Version 2.4.6 wurden auch schon wieder etwa siebzig Tickets abgeschlossen.

Während man bei Groovy also zunächst kleinere Brötchen bäckt, gibt es bei Grails aufbauend auf dem letzten großen Re-lease 3.0 noch einiges zu tun. Schon im Januar 2016 folgte Version 3.1 mit ausge-bauten Profile-Support und zum Beispiel Profilen für REST und AngularJS. Außer-dem wurde die Persistenz-Schicht GORM komplett überarbeitet und es werden jetzt neue Versionen von Hibernate, MongoDB, Neo4j und Cassandra unterstützt. Bereits im zweiten Quartal soll dann schon Version 3.2 mit weiteren Verbesserungen am REST

bzw. AngularJS Support und am Grails Ob-ject Relational Mapping (GORM) folgen, unter anderem für nicht-blockierende Aufrufe. Anschließend will man wieder in den jährlichen Release-Prozess wechseln. Grails 3.3 ist für 2017 angekündigt, unter anderem mit Non Blocking IO, basierend auf Netty. Dass sich OCI viel vorgenommen hat, sieht man auch daran, dass weiterhin bezahlte Mitstreiter für das Grails-Projekt gesucht werden.

FazitAlles in allem scheinen die erzwungenen Änderungen beiden Projekten gutgetan zu haben, wenn auch auf unterschiedliche Art und Weise. Bei Grails ist es anscheinend op-timal verlaufen – es gibt weiterhin eine Fir-ma, die vor allem ein wirtschaftliches Inter-esse am Fortbestehen des Frameworks hat. Hoffen wir, dass sich OCI nicht verhebt und Grails lange begleiten wird.

Für Groovy sah es zunächst düsterer aus. Aber gerade der Wechsel zur Apache Foundation wird dem Projekt in Zukunft viele Türen öffnen und neue Nutzer be-scheren. War man bisher zu stark von der Politik einer einzelnen Open-Source-Firma abhängig, hat man nun eine starke unab-hängige Gesellschaft mit sehr gutem Ruf im Rücken. Die Popularität scheint damit jetzt schon gewachsen zu sein, wenn man Statistiken wie dem Tiobe-Index (von Platz 80+ mittlerweile in die Top 20 [6]) oder den offiziellen Downloadzahlen (2015 mehr als verdoppelt im Vergleich zum Vorjahr) Glau-ben schenken mag.

Positiv ist natürlich, dass neben Grails noch einige weitere, vor allem schon eta-blierte Bibliotheken und Frameworks im Groovy-Umfeld existieren (wie Spock, Grad-le und Ratpack). Hinzu kommt, dass auch viele Java-Bibliotheken auf Groovy als DSL oder Skriptsprache setzen. Groovys beson-dere Features (etwa Closures oder Builder) und die ausdrucksstarke Syntax scheinen zudem Treiber für andere etablierte (Java 8) oder neue Sprachen (Swift) gewesen zu sein.

Obwohl das Interesse bei Konferenzen und in Magazinen im Vergleich zur Anfangs-zeit natürlich spürbar zurückgegangen ist, existieren noch einige kleinere Veranstal-tungen (GR8Conf, Greach, Spring 2GX), die sich nur dem Groovy-Ökosystem widmen. Und bei dem einzigen, aber hochgelobten Groovy-Vortrag auf der letztjährigen WJAX in München gab es über Twitter Anfragen/

| 49

www.ijug.euiii

iii iiiiii

Java aktuell 2-2016

Empfehlungen an die Organisatoren, das Thema statt im Keller mal wieder im Ballsaal anzubieten.

Die Webseite listet zudem einige nam-hafte Firmen auf, die Groovy verwenden. Natürlich weiß man nicht, in welchem Um-fang. Aber genau das ist ja eine der Stärken: Groovys Universalität von Skripten bis hin zu ausgewachsenen Enterprise-Anwen-dungen. Von daher eine klare Empfehlung, Groovy und gegebenenfalls auch Grails mal (wieder) eine Chance zu geben.

Falk Sippach hat mehr als fünfzehn Jahre Erfahrung mit Java und ist bei der Mannheimer Firma OIO Orientation in Objects GmbH als Trainer, Software-Entwickler und Projektleiter tätig. Er publiziert regelmäßig in Blogs, Fachartikeln und auf Konferenzen. In seiner Wahlheimat Darmstadt organisiert er mit Anderen die örtliche Java User Group. Falk Sippach twittert unter @sippsack.

Falk Sippachfalk.sippach@oio.de

Referenzen[1] Gardners Hype-Kurve: https://de.wikipedia.org/

wiki/Hype-Zyklus[2] About being a paid OSS Developer for Groovy:

http://blackdragsview.blogspot.de/2015/04/about-being-paid-oss-developer-for.html

[3] Who is Groovy: http://melix.github.io/blog/2015/02/who-is-groovy.html

[4] Groovy 2.4 And Grails 3.0 To Be Last Major Releases Under Pivotal Sponsorship: http://blog.pivotal.io/pivotal/news-2/groovy-2-4-and-grails-3-0-to-be-last-major-releases-under-pivotal-sponsorship

[5] Moving Groovy to a Foundation: http://www.groovy-lang.org/mailing-lists.html#nabble-td5722483

[6] Tiobe-Index: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

• Eine Funktion generiert beim Start der Applikation die GUI aus dem Anfangs-Modell

• Callbacks am Modell machen aus einer Veränderung des Modells eine Verände-rung der GUI

Der zweite Punkt hat es in sich, weil es oft gar nicht so einfach ist, eine Veränderung der GUI zu finden, die genau der Verände-rung des Modells entspricht. Außerdem gibt es Callbacks nicht nur vom Modell in die GUI,

„View“. Unterschiede zwischen Patterns wie MVC oder MVVM sind für die Zwecke dieses Artikels nebensächlich. Damit die GUI stets den korrekten Zustand des Modells anzeigt, muss das Modell sie über Änderungen infor-mieren. Bei „Native“-Toolkits für Java (Swing, SWT und JavaFX) geschieht das in der Regel durch „Callbacks“ im Modell, um die GUI zu verändern, in Java gern über das Observer-Pattern (siehe Abbildung 1).

Eine solche Applikation steuert die GUI auf zwei verschiedene Arten:

HTML5 ist eine echte Alternative zu den „Native“-Toolkits. Diese Option wird beson-ders attraktiv durch React, das GUI-Frame-work für HTML5 von Facebook. Es erschließt eine völlig neue Art der GUI-Programmie-rung. Noch besser lässt sich React mithilfe von ClojureScript und dem React-Wrapper Reacl programmieren.

Zunächst einige grundsätzliche Gedan-ken zur GUI-Programmierung: Eine vernünf-tige GUI-Architektur setzt auf die Trennung von „Modell“ (oder „Business-Logik“) und

Frontend-Entwicklung mit ClojureScript und React/Reacl

Michael Sperber, Active Group GmbH

Welches ist das beste Framework, um ein GUI-Frontend in Java zu entwickeln? Swing, SWT oder gleich JavaFX? Es geht auch ganz anders: Seit Java 8 wird ein kompletter Web-Browser mit HTML5 und JavaScript mitgeliefert. So können JavaScript-Anwendungen auch innerhalb von Java-Anwendungen laufen.

14 |

Groovy und Gra i ls

Groovy und Grails – quo vadis?Falk Sippach, OIO Orientation in Objects GmbH

Die Turbulenzen des Jahres 2015 haben Groovy und Grails zwar gut überstanden, inhaltlich gingen die Neuerungen der letzten Releases allerdings etwas unter. Dabei hat sich trotz aller Probleme wieder eine Menge getan.

Darum wollen wir in diesem Artikel einen Blick auf die Änderungen werfen, zunächst aber die typischen Eigenschaften zusammentragen und auch Kritikpunkte diskutieren.

heres Baby (Groovy) twittern. Groovy lässt sich auf vier Hauptprinzipien reduzieren: Feature-Reichtum, Java-freundlich, dyna-misches Groovy und robuste Plattform als Basis.

Feature-Reichtum: Auf der einen Sei-te bietet Groovy eine sehr ausdrucksstar-ke Syntax. Hat man sie einmal kennen und lieben gelernt, vermisst man sie schnell in reinen Java-Projekten. Zu nennen wären da stellvertretend die native Unterstützung für Collections inklusive der Wertebereiche (Ranges), die Verarbeitung von regulären Ausdrücken, GStrings, mehrzeilige Zeichen-ketten, der Property-Support, das Überladen von Operatoren und vieles mehr. Ebenfalls sehr praktisch sind die eingebauten Verarbei-tungsmöglichkeiten für XML und JSON sowie die einfachen Datenbank-Zugriffsmöglich-keiten. Die Laufzeit-Meta-Programmierung (MOP), die Compiletime-Meta-Programmie-rung mit AST-Transformationen und Traits (Mehrfachvererbung) ermöglichen es, beste-henden Code sehr flexibel zu erweitern. Eine der grundlegenden Eigenschaften sind die anonymen Funktionen (Closures), auf denen viele andere Sprach-Konstrukte aufbauen. Sie geben der Sprache zudem einen funktio-nalen Anstrich.

Java-freundlich: Durch die große Ähn-lichkeit mit der Java-Syntax lässt es sich mit Groovy sehr schnell loslegen, sei es in Tests, Skripten, als DSL (Spock, Gradle), zur Andro-id-Entwicklung oder natürlich in Enterprise-Anwendungen (Grails). Als Superset der Java-Syntax ist gerade für Java-Entwickler die Lernkurve flach und die Migration von bestehenden Anwendungen einfach mög-lich. Groovy integriert sich nahtlos in Java und wird auch zu Bytecode kompiliert. Zu-

dem können wechselseitig Klassen verwen-det werden (Aufruf, Vererbung, Relationen). Dadurch kann Groovy als Basis das JDK wie-derverwenden, erweitert es im GDK (Groovy Development Kit) aber auch um viele nützli-che Funktionen.

Dynamisches Groovy: Bekannt wurde Groovy als dynamische Skriptsprache. Die-ses Image hat in den letzten Jahren allerdings mehr geschadet, denn die dynamische Typi-sierung und die darauf aufbauende Laufzeit-Metaprogrammierung können so manchen Java-Entwickler überfordern, wenn er nur statisch getypten und damit vom Compiler geprüften Code gewohnt ist.

Als Alternative gibt es mittlerweile aber auch Traits und die Compiletime-Meta-Pro-grammierung mit AST-Transformationen. Damit werden die Erweiterungen schon im Kompiliervorgang hinzugefügt, was sich po-sitiv auf die Laufzeit-Performance und die Stabilität gerade von großen Projekten aus-wirkt. Zudem kann auch noch die statische Typprüfung aktiviert und, sofern gewünscht, der Sourcecode statisch kompiliert werden.

Aber auch die Runtime-Meta-Program-mierung hat weiterhin ihre Berechtigung, ermöglicht sie doch gerade für Domain Spe-cific Languages (wie in Grails, Gradle, Spock) oder in kleinen Skripten das Schreiben von kompaktem und Boiler-Plate-freiem Code, der dynamisch zur Laufzeit ganz flexibel um neue Funktionalitäten erweitert wird. Die Builder (für XML, JSON, Swing etc.) oder das Überladen von Operatoren sind typische Beispiele dafür.

Robuste Plattform als Basis: Da der Source-code zu Java-Bytecode übersetzt wird, profitiert Groovy als JVM-Sprache von allen Vorteilen der Java-Laufzeit-Umgebung. Das

Groovy hat seit jeher eine treue Fangemein-de (siehe Artikel in der letzten Ausgabe). Ein Großteil der Java-Entwickler meidet die Sprache aber, weil es sich ja „nur“ um eine dynamisch typisierte Skriptsprache han-delt. Für Irritation hat in Jahr 2009 auch die Aussage von James Strachan [1], einem der Gründer, gesorgt: „I can honestly say if some-one had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I’d probably have never created Groovy.”

Man darf diese Aussage allerdings nicht falsch verstehen und sollte sich den gesam-ten Kontext des Blog-Beitrags anschauen. James Strachan hatte damals über einen Nachfolger von Java philosophiert. Groovy stand natürlich auch auf der Kandidaten-liste. Durch die statische Typisierung und die mächtigen Typ-Inferenz-Mechanismen war Scala zu diesem Zeitpunkt für ihn aber die bessere Alternative zu Java. Das da-mals noch rein dynamisch typisierte Groovy konnte er sich nicht als kompletten Ersatz für Java vorstellen.

Auch heute lassen sich Groovy und Scala nur schwer vergleichen, auch wenn es Ge-meinsamkeiten gibt. Letztlich verfolgen sie jedoch ganz unterschiedliche Ansätze und haben sich jeweils eine Nische in der Welt der alternativen JVM-Sprachen erkämpft. Als Ersatz oder Nachfolger für Java hat sich keine der beiden Sprachen durchset-zen können. Immerhin haben sie durch ihre mächtigere Syntax und den größeren Funk-tionsumfang Java vor sich hergetrieben. Das mündete letztendlich mit Version 8 im größ-ten Update der Java-Geschichte. Und auch James Strachan sieht man in letzter Zeit wieder häufiger wohlwollend über sein frü-

| 15

www.ijug.euiii

iii iiiiii

Java aktuell 3-2016

bedeutet auch, dass die Java-Klassenbiblio-thek (JDK) und überhaupt alle Java-Bibliothe-ken einfach wiederverwendet werden kön-nen. Als Entwickler muss man zudem nicht umdenken, da das gleiche Speicher-, Threa-ding-, Vererbungs- und Sicherheitsmodell zur Anwendung kommt. Alle lieb gewonnenen Werkzeuge (Build-Tools, IDEs, Profiler, De-bugger ...) können meist „1:1“ oder mit kleinen Einschränkungen weiterverwendet werden.

KritikpunkteDa wo Licht ist, ist natürlich auch Schatten. Denn gerade wenn man Groovy als General Purpose Language in großen Projekten ein-setzt, stößt man schnell auf einige Proble-me. Wie so oft gilt: „There is no free lunch“ (Herb Sutter). Man kann nicht die Vorteile von Groovy nutzen, ohne auch einige Kom-promisse in Kauf zu nehmen. Diese sind nicht unbedingt als Nachteil zu werten, man muss sich aber mit den möglichen Konse-quenzen auseinandersetzen und vor allem verstehen, warum es sich so verhält. Bei Java geht es uns nicht anders, auch da leben wir mit gewissen Nachteilen. Am häufigsten wird bei Groovy die dynamische Typisierung mit all ihren Folgeerscheinungen kritisiert:

• Fehler erst zur Laufzeit• Fehlende Tool-Unterstützung bei Code-

Vervollständigung• Unsicherheit beim Refactoring• Schlechtere Performance

Kommt man aus der Java-Welt, ist man na-türlich gewohnt, dass der Compiler bereits viele Fehler entdeckt. Beim Refactoring er-hält man so direktes Feedback, wenn sich der Code nicht mehr übersetzen lässt. Zu-dem können durch die statische Kompilie-rung Optimierungen vorgenommen werden, die die Performance positiv beeinflussen. Aber auch wenn die dynamische Typisierung zunächst ungewohnt ist, so stellt sie doch eine der wichtigsten Funktionen von Groo-vy dar. Dierk König sagt dazu: „In OO, static types limit your choice. That makes dynamic languages attractive …”

Gerade bei kleineren Aufgaben (wie Skripten) helfen optionale Typen und Meta-Programmierung dabei, die Intention des Codes zu präzisieren. Vom Ballast befreiter Quellcode ist zudem viel besser verständ-lich. Das ist nicht zu unterschätzen, wenn man bedenkt, dass man ihn zu 80 Prozent der Zeit liest. Außerdem fällt es einfach leichter, gewisse Design- und Clean-Code-

Prinzipien einzuhalten beziehungsweise umzusetzen.

Die Groovy-Entwickler haben die kritischen Stimmen vernommen und so gibt es seit eini-ger Zeit Alternativen zur dynamischen Typisie-rung und zur Laufzeit-Meta-Programmierung. Mit den AST-Transformationen „@TypeChe-cked“ und „@CompileStatic“ kann man den Groovy-Compiler zu strengen Prüfungen und sogar zur statischen Kompilierung zwingen. An den annotierten Codestellen lassen sich dann allerdings keine dynamischen Fähig-keiten nutzen, die beiden Vorgehensweisen können jedoch innerhalb einer Anwendung kombiniert werden. Und für die Meta-Pro-grammierung stehen mit Traits (Mehrfachver-erbung) und AST-Transformationen Compiler-basierte Alternativen zur Verfügung.

Will man weiterhin mit dynamisch typi-sierten Anteilen umgehen, empfiehlt sich zur Qualitätssicherung natürlich auch eine gute Testabdeckung. In Java-Programmen haben wir diesen Anspruch doch ebenfalls. Groovy zwingt uns durch die fehlende Com-piler-Unterstützung also nur stärker zu die-ser Vorgehensweise. Gleichzeitig lassen sich in Groovy die Tests einfacher schreiben. Da-durch wird der Test-Code kürzer, ausdrucks-stärker und besser verständlich, zudem sind Mocking-Funktionalitäten bereits eingebaut und Tools wie Spock oder Geb verwenden sowieso Groovy-DSLs. Durch eine hohe Test-abdeckung werden auch die Fehler aufge-deckt, die in einer statisch getypten Sprache sonst durch den Compiler gefunden worden wären. Zusätzlich werden aber auch viele Szenarien getestet, bei denen der Compiler nicht helfen würde. Das klingt doch irgend-wie nach einer Win-Win-Situation.

Durch die statische Kompilierung entfal-len auch die Performance-Nachteile, da der erzeugte Bytecode ähnlich optimiert wer-den kann wie der von Java. Aber auch bei dy-namisch typisiertem Groovy-Code wurden in den letzten Versionen immer wieder klei-nere Optimierungen vorgenommen, sodass sich die Situation in den vergangenen Jahren stetig verbessert hat. Der größte Geschwin-digkeitszuwachs wird die noch ausstehende Überarbeitung des Meta Object Protocol auf Basis von Invoke Dynamic bringen. Leider ist aktuell nicht klar, ob und wann dieser Um-bau erfolgen wird. Allerdings geht es beim Großteil der Anwendungsfälle selten um das Herauskitzeln der letzten Millisekunden; die Flaschenhälse liegen oftmals an ganz ande-ren Stellen (wie Datenbank-Abfragen) und für die Implementierung von Real-Time-

Systemen wird man Groovy eher nicht ver-wenden.

Groovy hebt sich von Java nicht nur durch die dynamischen Fähigkeiten, sondern auch durch viele kleine nützliche Funktionen ab. Man könnte jede Menge nennen, stellver-tretend sind hier die inoffiziellen Top 5 kurz an Beispielen illustriert (siehe Listing 1):

• Mehrzeilige Strings und Zeichenketten mit Platzhaltern

• Elvis-Operator• Vereinfachte Objekt-Navigation und si-

cheres De-Referenzieren• Eingebauter Support für das Lesen und

Schreiben von Datenformaten (XML, JSON etc.)

• Power-Asserts

Das war jedoch nur die Spitze des Eisbergs, genauso erwähnenswert wären zum Beispiel:

• Multiple Assignments• Null Object Pattern• Spaceship-Operator• Diverse GDK-Methoden und -Operatoren• Diverse AST-Transformationen• Dynamische Method-Interception• Default-Parameter in Methoden

Eine Aufstellung dieser Hidden Features steht unter [2]. Aufgrund der Mächtigkeit der Spra-che darf ein Punkt jedoch auch nicht verges-sen werden: „With great power comes great responsibility“. Man kann Dinge machen, von denen Java-Entwickler nur träumen können. Aber gerade deshalb sollte man Vorsicht walten lassen, insbesondere in gemischten Teams mit reinen Java-Entwicklern. Was für einen Groovy-Fan elegant aussieht, ist für ei-nen anderen Kollegen ein Buch mit sieben Sie-geln. Deshalb sollte man zum Beispiel einheit-liche Code-Konventionen festgelegt. Über den Einsatz statischer Code-Analyse-Tools (Code-Narc) und die statische Typprüfung empfiehlt es sich ebenfalls nachzudenken.

Neuerungen der letzten ReleasesDass Groovy kein One-Hit-Wonder ist, sieht man an den regelmäßig veröffentlichten Versionen (mindestens einmal pro Jahr). Da die Sprache mittlerweile mehr als zwölf Jahre alt ist, darf man allerdings keine bahn-brechenden Neuerungen mehr erwarten. Es gibt jedoch stetig kleine Fortschritte, um die Verwendung einfacher und effizienter zu machen. Das letzte große Release war

16 |

Groovy und Gra i ls

Version 2.4 Anfang 2015. Danach gab es nur noch kleinere Bugfix-Releases, bei denen sehr viel Aufwand in die Erfüllung der Be-dingungen der Apache Software Foundation gesteckt werden musste. Die markantesten Neuerungen der letzten drei Minor-Relea-ses waren:

• Neue AST-Transformationen• Traits• Android-Support

Der Groovy-Compiler bietet bereits seit der Version 1.6 die Möglichkeit, in den Kompilie-rungslauf einzugreifen, um beispielsweise zusätzliche Anweisungen einzufügen oder zu löschen („AST“ steht für „Abstract Syn-tax Tree“). Damit können klassische Quer-schnittsprobleme wie Autorisierung, Tracing oder die Transaktionssteuerung gelöst wer-den, ohne den Sourcecode mit unnötigem Ballast aufzublähen. Vergleichbar ist dieser Mechanismus mit der Vorgehensweise der Java-Bibliothek Lombok, bei Groovy ist er allerdings direkt in die Sprache integriert.

Regelmäßig kommen neue Implemen-tierungen von AST-Transformationen hinzu. Eigene zu schreiben, ist auch möglich. Man unterscheidet zwischen globalen und lokalen AST-Transformationen, bei letzteren werden die anzupassenden Codestellen durch Anno-tationen markiert. Der Compiler kann dann an diesen Stellen zusätzliche Informationen in den Bytecode generieren. Der Sourcecode bleibt so schlank, also gut les- und wartbar.

Da die generierten Informationen im Byte-code landen, können aber auch andere (Java-)Klassen diese Funktionalitäten aufrufen. Es folgt mit dem Builder Design Pattern ein Bei-spiel für eine lokale AST-Transformation. Die Implementierung der Builder-Klasse existiert dabei nur im Bytecode (siehe Listing 2).

Neben dem Builder gibt es eine große An-zahl von fertigen AST-Transformationen [3] und es kommen ständig neue dazu. Die Trans-formationen können in verschiedene Kate-gorien einsortiert werden: Code-Generation („@ToString“, „@EqualsAndHashCode“ etc.), Klassen-Design („@Immutable“, „@Single-ton“ etc.), Logging-Erweiterungen („@Log“, „@Log4j“ etc.), deklarative Nebenläufigkeit („@Synchronized“ etc.), Compiler-Hinweise („@TypeChecked“, „@CompileStatic“, „@PackageScope“ etc.), Auflösen von Abhän-gigkeiten (Dependency Management mit „@Grab“) und viele mehr.

In der Dokumentation finden sich weite-re Informationen. Auch Grails macht mitt-lerweile starken Gebrauch davon und kann seine Magie so sehr stabil und auch per-formant umsetzen. Das Schreiben eigener Transformationen ist übrigens nicht ganz trivial, es gibt jedoch einige Tools (wie AST-Browser) und mittlerweile auch Tutorials, die bei der Umsetzung unterstützen.

Traits wurden Anfang 2014 in Versi-on 2.3 in Groovy eingeführt. Seit Version 8 gibt es mit Default-Methoden in Java eine vergleichbare, aber nicht ganz so mächtige Alternative. Letztlich handelt es sich um ei-nen Mehrfachvererbungs-Mechanismus; in Groovy gab es mit der AST-Transformation „@Mixin“ bereits seit Version 1.6 eine Vor-gänger-Umsetzung. Diese hatte allerdings einige Probleme und so wurde das Konzept mit Traits direkt in die Sprache integriert. Das Ziel ist es, einzelne Funktionalitäten in eigene Interfaces herauszuziehen („Sing-

String s = “““Dieser GStringreicht über mehrere Zeilen und kann Platzhalter verwenden: ${person.foobar}“““

// von if/else zum Elvis-Operatordef username = getUsernameFromAnywhere()if (username) { username } else { ‘Unknown‘ }username ? username : ‘Unknown’username ?: ‘Unknown’

// Null-Safe Dereferenz Operatorbank?.kunden?.konten?.guthaben?.sum()

// XML parsendef text = ‘‘‘ <list> <technology> <name>Groovy</name> </technology> <technology> <name>Grails</name> </technology> </list>‘‘‘

def list = new XmlSlurper().parseText(text) assert list.technology.size() == 2

// Power Assertsgroovy> a = 10 groovy> b = 9 groovy> assert 89 == a * b Exception thrown

Assertion failed:

assert 89 == a * b | | | | | 10| 9 | 90 false

Listing 1

@Builderclass Person { String firstName, lastName int age}

def person = Person.builder() .firstName(“Dieter”) .lastName(“Develop”) .age(21) .build()

assert person.firstName == “Dieter“assert person.lastName == “Develop“

Listing 2

| 17

www.ijug.euiii

iii iiiiii

Java aktuell 3-2016

le Responsibility“-Prinzip) und später über Vererbung wieder zu kombinieren.

Bis zur Einführung der Default-Methoden war in Java keine Mehrfachvererbung mög-lich – genaugenommen auch nicht gewollt. In Java 8 wurde sie aus der Not heraus hin-zugefügt. Durch das Stream-API mussten die Interfaces des Collection-Frameworks erweitert werden. Ohne Default-Methoden wären alle bisherigen Implementierungen kaputtgegangen, die Abwärtskompatibilität wäre gebrochen gewesen. Traits können im Gegensatz zu Java-Interfaces nicht nur Me-thoden, sondern auch Zustände enthalten (siehe Listing 3). Subklassen können dann von beliebig vielen Traits ableiten und erben sowohl die Variablen als auch die Methoden (siehe Listing 4).

Wie bei Interfaces üblich, dürfen Traits abstrakte Methoden definieren, sodass Subklassen diese überschreiben müssen. Das kann beispielsweise für die Implemen-tierung des Template Method Pattern inte-ressant sein. Dass in Java lange Zeit keine Mehrfachvererbung angeboten wurde, hing in erster Linie mit der Angst vor Konflikten in der Vererbungshierarchie zusammen. Das allgemein bekannte Diamond-Problem wird in Groovy aber relativ einfach umgangen (siehe Listing 5).

Es gewinnt nämlich automatisch das zu-letzt in der „implements“-Liste stehende Trait, wenn die aufzurufende Methode ermit-telt wird. Möchte man die Auswahl steuern, kann man entweder die Reihenfolge anpas-sen oder explizit den Super-Aufruf imple-mentieren (siehe Listing 6).

Traits können übrigens auch ganz dy-namisch zur Laufzeit von Instanzen einer Klasse implementiert werden. Dann ist man zwar wieder bei der langsameren Runtime-Meta-Programmierung, kann aber sehr fle-xibel bestehende Objekte um neue Funktio-

nalitäten ergänzen. Übrigens kann ein Trait mit einer abstrakten Methode (SAM-Type) auch über eine Closure instanziiert werden, ähnlich wie das bei Java 8 mit Lambda-Aus-drücken und Functional Interfaces der Fall ist. Weitere Beispiele finden sich unter [4].

Seit Anfang 2015 (Version 2.4) lassen sich Android-Apps mit Groovy entwickeln. Android-Entwickler profitieren dabei auch wiederum von Groovys prägnanter Syntax und den Meta-Programmierungsmöglich-keiten. In Java entwickelte Android-Anwen-dungen enthalten typischerweise viel Boiler Plate Code. Zudem stehen die modernen Errungenschaften aus Java 8 noch nicht zur Verfügung. Groovy bringt mit der Swiss Knife-Bibliothek zudem einige AST-Transforma-tionen mit, sodass häufig wiederkehren-de Funktionen (Behandeln von UI-Events, Verarbeitung in Background-Threads) sehr schlank implementiert werden können.

Wir haben gesehen, dass es in Groovy in den vergangenen Jahren keine technischen Revolutionen gab. Das liegt allerdings haupt-sächlich an der Ausgereiftheit der Sprache, die nur wenige Wünsche offenlässt. Trotz-dem wurden evolutionsartig kleine Verbes-serungen und Neuerungen eingebaut. Wie sich das unter der Obhut von Apache ohne kommerzielle Firma im Rücken entwickeln wird, muss sich noch zeigen. Ganz anders ist es bei Grails verlaufen. Da gab es mit Versi-on 3.0 im Frühjahr 2015 geradezu ein Feu-erwerk an Änderungen, damals noch unter der Ägide von Pivotal. Aber durch die Über-nahme durch die Firma OCI ist weiterhin Zug in dem Open-Source-Projekt, wie auch das Release 3.1 und die in der Roadmap [5] ge-planten Versionen beweisen.

Im Jahre 2005 erblickte Grails das Licht der Welt und war letztlich die Antwort der Groovy-Welt auf das Web-Application-Framework Ruby on Rails. In Anlehnung da-

ran wurde ursprünglich der Name gewählt („Groovy auf Schienen“), durch die Abkür-zung ist man nun aber eher auf der Suche nach dem heiligen Gral.

Grails ist geprägt von einigen Prinzipien für sauberes, objektorientiertes Software-Design wie „DRY“ (Don’t Repeat Yourself), „SRP“ (Single Responsibility) und „CoC“ (Convention over Configuration). Das heißt zum Beispiel, dass statt einer komplexen Konfiguration einfach Konventionen für die Namensgebung von Objekten einzuhalten sind, aus denen sich das Zusammenspiel zur Laufzeit automatisch ergibt. Diese Ei-genschaften ermöglichen eine rasche Um-setzung von Anforderungen, wodurch Grails seit jeher ein beliebtes Prototyping-Frame-work ist, das zudem auch optisch sehr an-sprechende Ergebnisse liefert. Vor mehr als zehn Jahren hatten die klassischen Java-Webanwendungen einige Tücken:

• Aufwändiges Editieren von Konfigurati-onsdateien

• Notwendige Anpassungen des Deploy-ment-Deskriptors („web.xml“)

• Aufwändige Konfiguration der Abhängig-keiten

• Umständliche Build-Skripte• Primitive Template- und Layout-Mecha-

nismen• Neustarten der Anwendung beziehungs-

weise des Webcontainers nach Änderungen

trait Fahrbar { int geschwindigkeit void fahren() { “println Fahren mit ${geschwindigkeit} km/h!“}}

class Bobbycar implements Fahrbar {}new Bobbycar(geschwindigkeit:100).fahren()

trait A { String exec() { ‘A’ }}

trait B extends A { String exec() { ‘B’ }}

trait C extends A { String exec() { ‘C’ }}

class D implements B, C {}

def d = new D() assert d.exec() == ’C’

class D implements B, C { String exec() { B.super.exec() }}def d = new D()assert d.exec() == ’B’

Listing 3

Listing 4

Listing 5

Listing 6

18 |

Groovy und Gra i ls

Mit Grails wurde den Entwicklern die Arbeit deutlich erleichtert. Aus dem ursprünglichen Einsatzzweck für CRUD-Webanwendungen hat es sich mittlerweile zu einem gestande-nen Fullstack-Web-Application-Framework gemausert. Zu den Kernprinzipien zählen die gesteigerte Produktivität, die einfachere Ent-wicklung, die Erweiterbarkeit und die ausge-reiften Bibliotheken als stabile Basis.

Gesteigerte ProduktivitätGrails eignet sich wunderbar für das Bau-en von Prototypen. Durch sinnvoll gewählte Grundeinstellungen und einfache Konventi-onen lassen sich Redundanzen vermeiden und in kurzer Zeit beachtliche Ergebnisse erzielen. Hinzu kommen die mittlerweile auf Gradle aufbauende Entwicklungskon-sole, die einheitliche Projektstruktur, die durch Metaprogrammierung hineingemixten Enterprise-Funktionalitäten und die Ver-wendung von Groovy.

Die Einfachheit ergibt sich durch die prä-gnantere Syntax von Groovy, die einheitliche Persistenz-Schnittstelle (GORM, ursprüng-lich für Objekt-relationales Mapping erfun-den, mittlerweile aber auch für NoSQL-Datenbanken geeignet), die wohldefinierte Projektstruktur mit hohem Wiedererken-nungseffekt, Verzicht auf unnötige Konfi-gurationen, die automatische Injektion von fertig mitgelieferten Enterprise-Services und die Validierung von Daten anhand fle-xibler und leicht zu erweiternder Regeln. Grails folgt dem KISS-Prinzip („keep it sim-ple and stupid“) mit dem Ziel, unnötigen Boi-ler-Plate-Code zu vermeiden. Zudem kann per Scaffolding statisch oder dynamisch ein initiales Code-Gerüst generiert werden, das bereits die CRUD-Funktionalitäten vom Frontend bis zur Datenspeicherung abdeckt und sogar Restful-Schnittstellen anbietet. Man kommt somit in wenigen Minuten zu einer lauffähigen Applikation. Nur bei der Geschäftslogik kann und muss letztlich noch Hand angelegt werden.

Die Erweiterbarkeit zeigt sich durch den modularen Aufbau von Grails mit der Aus-tauschbarkeit von einzelnen Komponenten (Hibernate/RDBMS <=> NoSQL, Tomcat <=> Jetty etc.). Zudem kann der Kern von Grails über Plug-ins beliebig um weitere Funktio-nalitäten ergänzt werden. Auch die eigene Anwendung lässt sich über Plug-ins sauber strukturieren und einzelne Teile sind ent-sprechend leichter wiederverwendbar. Auf-bauend auf den gleichen Ideen wie dem Java EE Standard (Integration von Spring und Hi-

bernate) bringt es zudem seine Ablaufum-gebung in Form eines Webcontainers direkt mit und war durch die Entwicklungskonsole seit jeher quasi eine Art Vorgänger der heu-te so stark beworbenen Self-Contained-Systems. Da die aktuelle Version auf Spring Boot aufsetzt, können mittlerweile auch di-rekt ausführbare Fat-JARs erzeugt werden.

Stabile BasisGrails ist in erster Linie eine Menge Gluecode um bestehende mächtige Bibliotheken wie Spring, Hibernate und Sitemesh. Durch die Entwicklung in Groovy kann man den syn-taktischen Zucker von Grails voll ausnutzen. Als Build-Artefakt wird ein klassisches Java WAR erzeugt, das in Webcontainern einge-setzt beziehungsweise mittlerweile als Fat-JAR einfach ausgeführt werden kann. Leider ist nichts perfekt und so werden auch an Grails immer wieder Kritikpunkte laut:

• Problematisch in großen Projekten• Gebrochene Abwärtskompatibilität und

großer Aufwand bei Upgrades• Aktualität der Plug-ins• Unleserliche Stack-Traces

Auch wenn einige Erfolgsstories für große Projekte existieren, eignet sich Grails eher für überschaubare Projekte mit kleineren und möglichst homogenen Teams (etwa für Microservices). Gerade ein Mix von erfahre-nen Java- und enthusiastischen Groovy-Ent-wicklern kann schnell zu Konflikten und auf Dauer zu Unverständnis führen. Aus eigener Erfahrung empfiehlt es sich auf jeden Fall, projektübergreifende Code-Konventionen (Typ-Angaben hinschreiben, Verwendung von „return“ etc.) festzulegen, damit auch die Java-Entwickler den Groovy-Code lesen und ändern können. Zudem ist eine gute Test-abdeckung wichtig, um die Auswirkungen der dynamischen Funktionalitäten abfangen zu können und bei Refactorings wenigstens durch die Testläufe Feedback zu erhalten.

Letztlich gilt wie so oft das Pareto-Prin-zip. 80 Prozent der Anwendung (zumeist CRUD) lassen sich in Grails sehr einfach umsetzen. Die letzten 20 Prozent brauchen dann jedoch auf einmal einen Großteil der Zeit und erscheinen im Vergleich umständ-licher, aber natürlich nicht unlösbar. In Java fällt das nur nicht so auf, weil schon die ers-ten 80 Prozent deutlich mehr Aufwand be-deuten.

Die mangelnde Abwärtskompatibilität schlägt sich meist darin nieder, dass man ei-

nigen Aufwand investieren muss, um beste-hende Anwendungen auf die neueste Grails-Version zu aktualisieren. Geschuldet ist dies dem Innovationsdrang der Grails-Entwickler, die neuesten Techniken und Ideen rasch zu integrieren. Das wird umso aufwändiger, je länger man wartet. Darum sollte man immer frühzeitig updaten. Die Grails-Dokumentati-on unterstützt durch einen Migrationsguide. Und hat man doch mal einige Versionsup-dates ausgelassen, empfiehlt es sich, alle Än-derungen Schritt für Schritt und von Version zu Version abzuarbeiten.

Der modulare Aufbau von Grails hat zu einem riesigen Plug-in-Ökosystem ge-führt [6, 7]. Leider schwankt die Qualität sehr stark. Guten Gewissens kann man die Plug-ins der Core-Entwickler einsetzen, sie werden bei neuen Grails-Versionen zeit-nah angepasst und regelmäßig gewartet. Erkennen kann man sie über positive Be-wertungen des Voting-Systems und durch eine große Anzahl von aktiven Nutzern. Bei anderen, oft von Einzelkämpfern erstellten Modulen gilt es zunächst, einen Blick auf die Aktualität des Sourcecodes (letzte Com-mits), die Antworthäufigkeit bei Fragen und die Bearbeitung der Tickets zu werfen. Lei-der existieren nämlich einige Karteileichen, die durch die hochfrequente Update-Politik mit den aktuellen Versionen gar nicht mehr funktionieren. Da bleiben dann bei Interesse nur der Fork und die eigene interne Pflege des Plug-ins oder natürlich eine Weiterent-wicklung des Originals, sofern man sich das zutraut.

Aufgrund des großen Funktionsumfangs fällt es schwer, die wichtigsten Grails-Fea-tures zu benennen. Es gibt einfach zu viele nützliche Eigenschaften. Zudem setzt jeder Entwickler auch andere Prioritäten. Folgen-de Punkte sollen aber stellvertretend für viele andere stehen:

• Automatische Dependency Injection (etwa durch Namenskonventionen)

• Validierung der Domänen-Klassen (ähn-lich wie Java-EE-Validation-API)

• Sehr einfache, aber trotzdem mächtige Erweiterung durch Tag-Libs

• Automatisch generierte CRUD-Metho-den

• Viele Persistenz-Abfrage-Varianten wie die gut lesbaren „Where“-Queries

Bei jedem dieser Punkte könnte man wie-der ins Detail gehen. An dieser Stelle sei aber auf die Dokumentation verwiesen. In-

| 19

www.ijug.euiii

iii iiiiii

Java aktuell 3-2016

teressanter sind die neuesten Funktionen des letzten Release. Neue Minor-Versionen kommen ähnlich wie bei Groovy mindestens einmal pro Jahr heraus. Das letzte Major-Update (3.0) wurde im Frühjahr 2015 ver-öffentlicht. Die Liste der Neuerungen ist lang und beeindruckend. Die Maßnahmen versprechen eine verbesserte Stabilität und leichtere Integration in bestehende System-Landschaften:

• Spring Boot als Basis• Neues Interceptor-API• Anwendungsprofile• Gradle als Build-System• API-Redesign

Über Spring Boot braucht man mittlerweile nicht mehr viel zu schreiben. Viele seiner Ei-genschaften hatte Grails in ähnlicher Form schon sehr lange im Portfolio. Um sich aber den unnötigen Pflegeaufwand zu sparen, baut man nun auf dem vielfach bewährten Framework auf. Von Spring Boot profitiert Grails besonders durch die Einbettung des ausführenden Containers, der in einem lauf-fähigen JAR inkludiert wird. Damit kann man Grails-Anwendungen tatsächlich überall laufen lassen, es muss nur Java installiert sein. In der Entwicklung ist man zudem nicht mehr auf eine speziell angepasste IDE ange-wiesen, da eine Grails-Anwendung nun wie jede beliebige Java-Anwendung gestartet, auf Fehler überprüft und mit Profilen einge-richtet werden kann.

Das neue Interceptor-API ergänzt bezie-hungsweise ersetzt die Grails-Filter bei der Entwicklung von Querschnittsbelangen (Se-curity, Tracing, Logging etc.). Gewisse Basis-Funktionalitäten erben Interceptoren von einem Trait. Im Gegensatz zu den Filtern, die ähnlich Servlet-Filtern über Muster auf bestimmte URLs reagieren, werden Inter-ceptoren in der Regel über Namenskonven-tionen jeweils einem Controller zugeordnet. Gemeinsam ist beiden Ansätzen, dass sie verschiedene Callbacks („before“, „after“ und „afterView“) anbieten, über die Querschnitts-funktionalität implementiert wird. Intercepto-ren sind dazu noch kompatibel mit der stati-schen Kompilierung („@CompileStatic“), ein nicht zu verachtender Performance-Vorteil. Schließlich werden sie potenziell bei jedem Request aufgerufen. Weitere Informationen finden sich unter [8].

Eine andere Neuerung ist der Support für Anwendungsprofile. Gemeint ist hier die Struktur, die beim Anlegen eines neuen

Grails-Projekts gleich auf das gewünschte Szenario (Web-, REST-, RIA-Anwendung etc.) zugeschnitten werden kann. Es ist ein bisschen vergleichbar mit den Java-EE-Profilen („Web“ und „Full“), geht aber noch einige Schritte weiter. So kapselt ein Pro-fil die aufrufbaren Kommandos, Plug-ins, Skeletons/Templates und Ressourcen. Der Default ist übrigens weiterhin die klassische Web-Anwendung. Man kann auch eigene, firmenspezifische Profile anlegen, die dann in einem Repository (im User-Verzeichnis) gespeichert werden.

Grails hatte seit jeher ein auf Groovy, Ant und Ivy basierendes, selbst entwickel-tes Build-Management, auf dem auch die Kommandos für die Entwicklungskonsole aufgebaut haben. Aber gerade die Integra-tion in eine bestehende Systemlandschaft mit klassischen Java-Build-Tools wurde da-durch unnötig verkompliziert. Zudem war das Bauen mit Gant immer etwas proble-matisch. Seit Grails 3 wird als Build-System Gradle verwendet. Somit ist man auch hier nicht mehr abhängig von speziell integrier-ten Funktionen der IDEs. Das erleichtert den Abschied von der Eclipse-basierten „Groovy und Grails Toolsuite“, die seit dem Rückzug durch Pivotal nicht mehr weiterentwickelt wird. Es reicht theoretisch wieder ein einfa-cher Text-Editor mit der Kommandozeile, so wie Grails bereits vor mehr als zehn Jahren gestartet ist.

In Grails passieren viele Dinge automa-tisch, manchmal magisch. Das wurde in den älteren Versionen vor allem durch Laufzeit-Meta-Programmierung erreicht, war jedoch immer wieder die Quelle für Probleme und Instabilitäten im Entwicklungsprozess. Mitt-lerweile setzt man bei der Erweiterung von Domain-Klassen, Controllern, Services, Tag-Libs und Tests verstärkt auf Compiletime-Meta-Programmierungsmechanismen mit AST-Transformationen und auf Traits. Im Rahmen dieser Umbauarbeiten wurden gleich das API umstrukturiert und eine sau-bere Trennung in öffentliche („grails.*“) und private/interne Pakete („org.grails.*“) vorge-nommen.

Die stetig steigenden Downloadzahlen zeigen das wachsende Interesse. Wer nach dem hier Gelesenen (erneut) Lust auf Groovy und Grails bekommen hat, sollte sich selbst ein Bild machen, die neuesten Versionen installieren und einfach mal loslegen. Die Online-Dokumentation hilft beim Starten und zudem gibt es mittlerweile jede Menge Literatur und Tutorials zum Thema.

Referenzen[1] Blog James Strachan: http://macstrac.blogspot.

de/2009/04/scala-as-long-term-replacement-for.html

[2] Groovy Hidden Features: http://stackoverflow.com/questions/303512/hidden-features-of-groovy

[3] Available AST transformations: http://groovy-lang.org/metaprogramming.html#_available_ast_transformations

[4] Traits: http://blog.oio.de/2014/07/04/unterstut-zung-von-traits-ab-groovy-2-3/

[5] Grails Roadmap: https://github.com/grails/grails-core/wiki/Roadmap

[6] Grails-Plug-ins bis 2.x: https://grails.org/plugins[7] Grails-Plug-ins ab 3.0: https://bintray.com/grails/

plugins[8] Grails Interceptor: http://www.ociweb.com/re-

sources/publications/sett/september-2015-grails-3-interceptors

Falk Sippach hat mehr als fünfzehn Jahre Erfahrung mit Java und ist bei der Mannheimer Firma OIO Ori-entation in Objects GmbH als Trainer, Software-Ent-wickler und Projektleiter tätig. Er publiziert regelmäßig in Blogs, Fachartikeln und auf Konferenzen. In seiner Wahlheimat Darmstadt organisiert er mit Anderen die örtliche Java User Group. Falk Sippach twittert unter @sippsack.

Falk Sippachfalk.sippach@oio.de

Braintime kümmert sich darum, dass Ihre besten Köpfe ihre Hände frei haben.

OIO - Orientation in Objects GmbH I Weinheimer Str. 68 I 68309 Mannheim I Tel. +49 621 71839-0 I Fax +49 621 71839-50 I info@oio.de I www.oio.de

www.braintime.de

Braintime. Clevere Methoden, Werkzeuge und Lösungen für clevere Unternehmen.

• Scaling Agility - Scaled Agile Partner XP, Scrum, Kanban, SAFe

• Atlassian Platinum Partner JIRA, Confluence, Plugins, Lizenzen

• Clevere Lösungen Continuous Delivery, Web Publishing...

BRAINTIME