Groovy - Skriptsprache

Hintergrund:

• Groovy erfährt, wie Java auch, von Zeit zu Zeit größere Versions-Sprünge.

• Dabei wird Groovy an die neueren Java-Versionen angeglichen.

• Diese enthalten von z.B. 2.x zu 3.x, aber auch von 3.x zu 4.x einige Breaking-Changes an der API

• Die Verwendung dieser Konstrukte kann nach einem Update zu Laufzeitfehlern führen

  • Beispiele:
    for-in-Schleife => for-each-Schleife
    Anpassung von Imports

Fazit

• Es ist besser, die Java-Syntax zu verwenden

• Vereinfachte Schreibweisen für Listen oder Maps stellen aber kein Problem dar

Hintergrund:

• Im Jahr 2015 war es ungewiss, wie es mit Groovy weitergehen wird, da sich der Hauptsponsor Pivotal aus dem Projekt zurückgezogen hatte.

• Erst nach einigen Monaten stand fest, dass Groovy bei der Apache Foundation unterkommen wird.

• Wäre dies nicht passiert, hätte Groovy evtl. durch eine neue Skript-Sprache, damals noch nicht vollständig kompatibel zu Java 9 oder Java 11, ersetzt werden müssen.

Fazit:

• Nach dem aktuellen Kenntnisstand (2024) besteht hierfür keinerlei Anlass zur Sorge.

• Groovy erfreut sich einer großen Community und wird ständig mit den neuen Java-Versionen und eigene Sprach-Features erweitert.

Hintergrund:

• In früheren Java- und Groovy-Versionen unterschieden sich die Groovy-Closures von den Java-Lambda-Ausdrücken. Hier waren potenzielle Speicherlecks bekannt.

• Mit der Umstellung auf Java 9 und Groovy 3 sind diese Probleme aus dem Weg geräumt.

Fazit:

• Einfache Lambda-Ausdrücke für Comparatoren oder Filter bzw. für die Java-Stream-API können problemlos eingesetzt werden.

• Für die Lesbarkeit ist es aber anzuraten, Closure-Konstrukte nur in der ersten Ebene anzuwenden und damit potenziell verstecke Fehlerquellen zu vermeiden.

• Zusätzlich wird darauf hinzuweisen, dass für diese Konstrukte die Editor-Unterstützung fehlt und diese noch als Warnung angezeigt werden.

Hintergrund:

• Diese Klassen von Groovy erlauben ein vereinfachtes Schreiben von Json- und Xml-Code

• Je nach Komplexität der Strukturen bietet hier Groovy einen komfortablen lesenden wie schreibenden Zugriff

Fazit:

• Diese Klassen können in Skripte gefahrlos eingesetzt werden, mit der Version 24.3 werden sie offiziell unterstützt.

• CURSOR Software AG gewährt nur Support auf die vom Skript-Editor oder in den Util-Klassen unterstützten Standard-Klassen, für die keine gesonderte Import-Anweisung notwendig ist. Diese sind von uns getestet und entsprechend freigegeben.

• Externe Klassen sind durch einen gesonderten Import im Skript oder durch eine voll-qualifizierte Angabe des Klassennamens erkennbar.

• Werden Klassen aus der JBoss-Bibliothek oder dem Groovy-Umfeld hinzugefügt, kann CURSOR Software AG nach einem Update keine Funktionsgarantie mehr geben, da diese Bibliotheken in neueren Versionen vorliegen können und evtl. nicht mehr kompatibel sind.

• Werden externe Bibliotheken im JBoss eingebunden und in Skripten importiert, liegt die Verantwortung hierfür beim Skript-Ersteller (im Kundenprojekt).

• Der Support erlischt hiermit nicht für die gesamte Skript-Klasse oder den BPM-Prozess sondern nur für den entsprechenden Code-Abschnitt.

• In CURSOR-Skripten eigene Klassen zu erzeugen ist zwar möglich, bietet aber kaum einen Mehrwert

• Es fehlt die Code-Editor-Unterstützung für diese Klassen und für eine Json-Umwandlung kann bspw. auch ein Map-Objekt genutzt werden

• Diese Klassen können weder als Parameter- noch als Rückgabe-Typ in der Skript-Bibliothek verwendet werden

• Objekte dieser Klassen sind als Prozess-Variablen gültig. Die Klassen-Definition gilt nur lokal für dieses Skript und nicht global für die CRM-Anwendung, d. h. in anderen Skripten oder bei der Deserialisierung von Variablen in der Prozess-Engine.

  • Wird in zwei Skript-Aktionen "dieselbe" Klasse definiert, so sind es doch zwei unterschiedliche Klassen

• Eine Weiterverarbeitung dieser Objekte führte bereits zu bekannten Fehlern bei der Deserialisierung z. B. aus Prozessvariablen oder in den Rest-Schnittstellen!