© Excellent backgrounds/Shutterstock.com
Wartbare Frontends von Webanwendungen mit Java entwickeln

Zweiweltensymbiose


Wartbarkeit bzw. Abänderbarkeit sind kein Selbstzweck. Schlecht wartbare Software führt zu hohen Wartungs- und Weiterentwicklungskosten. Das ist besonders bei Webanwendungen ein Problem, da die Webentwicklung traditionell durch eine Vielzahl an verwendeten Auszeichnungs- und Programmiersprachen geprägt ist. Auf der anderen Seite zeichnet sich die Front­end-Entwicklung durch einen komfortablen Entwicklungsworkflow aus, bei dem Änderungen nach einem Neuladen im Browser sofort sichtbar sind. Wie kann man wartbare Webanwendungen entwickeln, ohne Abstriche beim Entwicklungsworkflow machen zu müssen?

In den letzten Jahren wurde der Umfang der Frontend-Entwicklung von Webanwendungen immer umfangreicher. In diesem Artikel wird unter Frontend alles verstanden, was nicht auf dem Server stattfindet. Daher bezieht sich die Clientseite im Folgenden auf den Browser als Ausführungsumgebung des Frontends. Wo früher die fertigen HTML-Seiten vom Server generiert und ausgeliefert wurden, bestehen heutzutage Webanwendungen teilweise nur noch aus einer einzelnen HTML-Datei (Single-Page-Webanwendung). Dabei wird die Benutzeroberfläche mittels JavaScript erstellt und dynamische Inhalte per Ajax nachgeladen. Durch diesen Wandel wurde JavaScript zum Dreh- und Angelpunkt der Front­end-Entwicklung. Es hat sich von der einst verpönten Skriptsprache für dynamisches HTML zu einer akzeptierten Programmiersprache entwickelt. Ein Grund dafür ist, dass auf der Clientseite die JavaScript-Laufzeitumgebungen der Browser immer schneller und die Browser-APIs mit HTML5 immer mächtiger werden. Mit Node.js hat JavaScript sogar den Sprung auf die Serverseite geschafft.

Mittlerweile ist dieser Trend auch in der Java-EE-Welt angekommen. So hat Java EE 7 Unterstützung für JSON und WebSockets erhalten, was der Entwicklung von Single-Page-Webanwendungen mit Java EE sehr entgegen kommt. So kommt etwa ThoughtWorks in ihrem Technology-Radar 2014 [1] zu dem Schluss, dass sie von der Verwendung von JSF abraten und stattdessen die Verwendung von Frameworks auf der Clientseite empfehlen. Oracle geht in Sachen JavaScript in Java EE mittlerweile sogar so weit, dass mit Projekt Avatar die Verwendung von JavaScript auf der Serverseite ermöglicht wird.

Problemstellung

Allerdings erschwert insbesondere die dynamische ­Natur von JavaScript die Verwendung der gewohnten IDE-Features, wie sie z. B. für Java zur Verfügung stehen. In Java-Code kann z. B. für jede Methode die Aufrufhierarchie ermittelt und für Variablen analysiert werden, wo sie im Code überall verwendet werden. Außerdem sind für Java mächtige Refactoring-Werkzeuge verfügbar, die es ermöglichen, Änderungen am Code auf eine konsistente und produktive Art und Weise durchzuführen. Schon alleine das Vorhandensein dieser IDE-Features hat einen großen Einfluss auf die Wartbarkeit bzw. Änderbarkeit, wie sie das Qualitätsmodell der ISO 25000 [2] (Kasten: „Kriterien für wartbare Software (ISO 25000)“) definiert. Denn schon die oben genannten IDE-Features sorgen für eine stark verbesserte Analysier- und Modifizierbarkeit.

Kriterien für wartbare Software (ISO 25000)

  • Analysierbarkeit

  • Modifizierbarkeit

  • Stabilität

  • Testbarkeit

  • Konformität

Und dabei ist JavaScript nur eine der verwendeten Notationen. Auf der Clientseite kommen noch HTML als Auszeichnungssprache und CSS als Formatierungssprache hinzu. Zusätzlich zu Java (und oft JSP) auf der Serverseite wird meist SQL als Datenbanksprache verwendet. Das führt dazu, dass in einer Anwendung sechs verschiedene Notationen verwendet werden. Dabei entstehen die Abhängigkeiten aus Abbildung 1. Jeder Abhängigkeitspfeil repräsentiert eine Menge von Bezeichnern, die in den verschiedenen Notationen konsistent verwendet werden müssen.

scheible_abb1.tif_fmt1.jpgAbb. 1: Abhängigkeiten der Notationen

Die als grüne Pfeile dargestellten Abhängigkeiten sind unvermeidbar. Die rot dargestellten Pfeile hingegen sollten nur in den GUI-Tests einer Webanwendung vorkommen, da oft auf das Vorhandensein von Elementen mit bestimmten HTML-IDs oder CSS-Klassen in den Java-Testfällen (z. B. mit Selenium [3]) gewartet werden muss. Durch diese Abhängigkeit wird bei der direkten Verwendung von HTML und CSS die Testbarkeit verringert, da die Testfälle immer an Änderungen des Front­end-Codes angepasst werden müssen. Die Testbarkeit ist ebenfalls ein Kriterium der Wartbarkeit im Qualitätsmodell der ISO 25000.

Selbst in modernen IDEs ist es weder möglich, die Konsistenz der Bezeichner bei Änderungen immer sicherstellen zu lassen, noch ist es möglich, zwischen den einzelnen Notationen zu navigieren. So verwundert es nicht, dass es in einer Podiumsdiskussion auf der Lang.NEXT 2012 zu folgendem Dialog kam [4]: „Erik Meijer: Are you saying you cannot write large programs in JavaScript? Anders Hejlsberg: No, you can write large programs in JavaScript. You just can’t maintain them.“

Lösungsansatz

Der Ansatz des Knorxx Frameworks ist es daher, die gesamte Codebasis in Java zu schreiben und alle anderen Zielnotationen zur Laufzeit aus ihr zu generieren. Dabei war es eine zentrale Anforderung, den gewohnten komfortablen Entwicklungsworkflow, trotz der Verwendung von Java als kompilierte Programmiersprache, beizubehalten, bei dem Änderungen nach einem Neu­laden im Browser sofort sichtbar sind. Außerdem war es ein Ziel, bereits existierenden serverseitigen Code möglichst unverändert zu lassen.

Die Konsistenz der Bezeichner wird durch die gemeinsame Codebasis erreicht, bei der die verschiedenen Teile der Webanwendungen durch Konstanten verbunden werden. Inkonsistenzen werden schon während des Schreibens des Codes in der IDE durch den Java-Compiler erkannt.

Im Folgenden wird zuerst die grundsätzliche Funktionsweise des Knorxx Frameworks beschrieben. Danach wird anhand von Beispielen die Verwendung illustriert.

Im Falle von JavaScript wird für die Generierung der clientseitigen Klassen ein Transpiler verwendet, also ein Quellcode-zu-...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang