Blog
As time goes by II
Wie schützt man sich vor dem Verschwinden seiner bevorzugten Tools und Technologien?
13. März 2025
Hier ein zweiter Post über die Vergänglichkeit von Technologien und wie man vorsorgen kann. Der Vorgänger ist hier nachzulesen.
Dass ein "Hyper Hyper" bei Technologien nicht vor dem plötzlichen Ende schützt, habe ich versucht im vorangegangenen Post über Flex und Flash zu schildern.
Ich nutze seit rund 15 Jahren am liebsten die Kombination von Groovy und Grails für Web-Anwendungen und APIs. Aber es wird langsam stiller um das tolle Gespann. Für Groovy gibt es mittlerweile eine Vorschau auf Version 5 und für Grails auf Version 7. Aber das Tempo hat nachgelassen. Kotlin ist für Groovy wirklich ein gelungener Konkurrent und Grails könnte in Micronaut aus dem gleichen Hause aufgehen, aber dann bleibt nichts mehr für klassische Webanwendungen, dann regieren die Micro-Services.
Jetzt ist das Ende des Lebenszyklus der beiden Technologien wirklich nicht abzusehen, es kann sein, dass sie sich noch viele, viele Jahre halten. Aber bei der Wahl einer Technologie für ein Projekt sollten nicht nur die persönlichen Vorlieben zählen, sondern auch Aspekte wie Zukunftssicherheit - sei es für eigene Projekte oder Kundenprojekte.
Was Groovy angeht bin ich sehr optimistisch. Ich habe in den letzten 24 Monaten wirklich viele Schulungen zum Thema Groovy gehalten und auch Consulting Jobs gemacht. Groovy eignet sich durch seine Art als Ergänzung zu Java und nicht als seine Ersetzung hervorragend dafür, große Enterprise-Anwendungen zu scripten.
Die größte Nachfrage bei den Schulungen sind die Themen, mittels Groovy Anpassungen an Jira und Confluence vorzunehmen. Dank des ScriptRunners kann man sowohl Jira als auch Confluence hervorragend scripten: Neue Workflows, Template, Reports, Macros u.v.a.m. bis hin zur script-gesteuerten Integration von Jira und Confluence.
Ein weiteres Schulungsthema ist das Steuern und Erweitern von Jenkins, dem bekannten Automations-Server. Auch hier liegen unendliche Möglichkeiten vor Jenkins-Instanzen so zu nutzen wie man möchte.
Schließlich ein nicht so bekanntes Beispiel, aber dennoch im Enterprise-Bereich bedeutsam: Die ERP Software PSI Penta hat in einem Major-Relase die Codebasis von .Net auf Java umgestellt. An sich schon ein bemerkenswerter Schritt. Aber für den Betrieb und die Anpassungen bedeutet das, dass alle Skripte von VB.net auf Groovy umgestellt werden müssen und die Oberfläche von .Net auf JavaFX umgestellt werden muss. Ein Riesenthema für Kunden von PSI und jede Menge Arbeit - es gibt kaum einen Bereich wie ERP, bei dem es so viele Anpassungen an das Grundprodukt gibt. Ich habe zwei solcher Migrationen/Updates mitgemacht und das werden nicht die letzten gewesen sein.
Von Grails ist zwar mittlerweile ein sehr schöner Fork entstanden in Form des Grace Framework, aber das wird das Projekt, wenn es einmal so weit sein sollte, nicht retten. Aber da Grails sehr stark auf SpringBoot aufsetzt (und letztlich eine Vereinfachung der Vereinfachung von Spring ist) wird man SpringBoot sicherlich nicht schnell gehen sehen, entspricht es doch dem maßgeblichen Industriestandard im Java-Bereich.
Und eine Umsetzung von Grails hin zu SpringBoot ist relativ einfach, zumal SpringBoot ja nicht nur mit klassischem Java zu verwenden ist, sondern auch mit Kotlin und - Trommelwirbel - Groovy.
Fazit: Immer ein waches Auge dafür haben, wie es um das Ökosystem der bevorzugten Technologien steht. Alternativen im Auge behalten und Migrations-Pfade offenhalten. Dann kann nicht mehr viel passieren.