Blog - Kategorie Java

Ich habe bei meinen aktuellen Java Web-Applikationen oft mit der Situation zu tun, dass verschiedene Handler der Applikation auf einen gemeinsamen Pool von Daten lesend (und manchmal auch schreibend) zugreifen müssen.

Das einfache Vorgehen, dass ich auch zu meinen PHP-Zeiten gewohnt war, ist es, eine Datenverbindung (soll heißen: eine offene MySQL-Verbindung) zu errichten oder aufrechtzuerhalten, und diese an alle Handler weiterzugeben, so dass diese die benötigten Daten unmittelbar aus der Datenbank lesen und Änderungen direkt in die Datenbank zurückschreiben können.

Allgemeine Überlegungen

Dieses “Read-On-Demand”-Verfahren hat aber ein paar häßliche Nachteile, weshalb ich es heute nicht mehr gerne einsetze:

• Die Daten aus der Datenbank müssen evtl. bei jedem Request neu eingelesen und verarbeitet werden. Das kann bei großen (oder komplizierten) Daten einiges an Verarbeitungszeit kosten
  (Beispielsweise dauert das Neueinlesen der Weblog-Daten aus diesem Blog schon ein paar Sekunden, da erst die enthaltenen Bilder nachgeprüft und verkleinert werden müssen, LaTeX-Formeln verarbeitet werden usw.)
• Bei einer Änderung der Datenschnittstelle (z.B: Änderung des Tabellenformats in der Datenbank) müssen alle Handler angepasst werden. Dabei kann man leicht eine Abfrage vergessen, die dann zu einem Bug führt.
• In jeden Handler muss das Lesen und Interpretieren der Daten (inklusive SQL-Abfragen) hineinprogrammiert werden, was den Aufwand zum Entwickeln eines Handlers stark erhöht. Oft ergibt sich dann doppelter Code, weil verschiedene Handler die selben Daten einlesen
• Bei mehreren gleichzeitigen Abfragen (wobei mindestens eine davon die Daten verändert) können Datenhazards auftreten, also eine Verfälschung der Daten durch eine falsche Verarbeitungsreihenfolge. Dadurch kann auch permanenter Datenverlust auftreten

Um diese Probleme zu umgehen bin ich seit kurzem auf Caches umgestiegen. Unter einem Cache verstehe ich eine gemeinsame Instanz, die den Zugriff auf eine bestimmte Datenmenge der Applikation zur Verfügung stellt:

Wenn man in Java mit komplexeren Strings arbeiten will, benötigt man oft Funktionen, um das Ergebnis aus einer Vorlage zu erzeugen, indem verschiedene Variablenwerte eingesetzt werden.
Vor allem, um Textdateien in einem bestimmten Format (z.B. CSV oder HTML) zu erzeugen, bei dem die Grundstruktur irgendwo entworfen und abgespeichert werden soll, macht ein Templatesystem für Strings Sinn.

Für die Web-Ausgabe gibt es JSP, um Inhalte in ein Template einzufügen und auszugeben.
Aber für lokale Anwendungen ist mir bisher kein solches System bekannt.
Einfache Sachen lassen sich ja in Java hartkodieren oder mit Suchen-und-Ersetzen-Methoden generieren, aber je komplizierter die Struktur wird, desto mehr Arbeit macht auch die Implementierung.

Um dieses Problem ein für alle Mal zu lösen, habe ich eine Template-Klasse geschrieben, die String-Templates mit folgenden Funktionen repräsentieren:

• Ersetzen von Variablen
• Auswählen von If-Then-Else-Verzweigungen
• Iterieren über Collections (mit Code-Duplikation)

Im Java-Umfeld hat sich die Datenspeicherung mit XML schon weitestgehend zum Standard durchgesetzt. Vor allem viele Konfigurationsdateien (z.B. fast alle Config-Dateien in der Java Servlet Engine „Apache Tomcat“ sind in XML gehalten) sind regelmäßig in XML notiert; aber auch viele andere Datendateien für Java-Programme werden in XML definiert, da sich für dieses Format die Validierung und das Parsing sehr einfach und generisch in Java (und anderen Tools) durchführen lässt.

Eine sehr gängige Methode für das Einlesen (und interne Verwalten) von XML-Daten liegt darin, das XML-Dokument in einen Baum zu transformieren.

Hierbei sind alle Knoten des Dokuments (Elemente, Attribute, Entitäten und CDATA) als Node-Objekt im Speicher repräsentiert, deren Eigenschaften als Membervariablen dieses Node-Objekts gelesen werden können (z.B. Tagname, Typ des Elements, Wert eines Attrubuts, …). Die einzelnen Node-Objekte sind über eine Vater-Söhne-Relation miteinander verbunden.

Das Einlesen eines XML-Dokuments in einen Baum kann mit vielen Java-Toolkits gemacht werden (z.B. mit DOM = Document Object Model)

Eine großer Nachteil bei dieser Methode ist es, dass man in seinem Java-Programm meist selbstständig den Baum durchlaufen und interpretieren muss.
Natürlich kann man mit Hilfsmitteln, wie XPath sehr gut und effektiv Anfragen auf den XML-Baum ausführen, aber den XML-Baum in seine Java-Datenstrukturen umwandeln muss man noch selbst.

Eine andere Möglichkeit, Java mit XML zu vereinen bringt JAXB (Java Architecture for XML Binding).

Ich arbeite im Moment an dem interessanten Projekt, einen Traffic-Generator zu schreiben.

Dabei sollen die Zwischenankunftszeiten und Paketgrößen nach wählbaren Verteilungsfunktionen mit frei wählbaren Parametern verteilt sein.

Ich verwende die Java-Bibliothek JSimLib (eine Eigenentwicklung des Lehrstuhls), um Zufallszahlen nach bestimmten Verteilungen zu erhalten.

Da es einige Verteilungsklassen gibt (und diese möglicherweise noch ergänzt werden), und diese Verteilungsklassen unterschiedlich viele Parameter akzeptieren, wird ein Java-Machanismus benötigt, der ein Verteilungsobjekt mit der richtigen Verteilungklasse und den richtigen Parametern aus den Argumenten der Java-Kommandozeilenargumente erstellt.

Hierzu verwende ich die Reflections-Klassen von Java, die es ermöglichen, zur Laufzeit Klassen und Objekte zu untersuchen und zu erstellen.

Ab Java 1.5 unterstützt die Programmiersprache Java die Verwendung von sogenannten “Generics” (auch generische Typen, parametrisierte Typen).

Die Idee dahinter ist es, dass sich viele Datenstrukturen, die Objekte von bestimmten Typen enthalten, für alle diese Typen gleich (oder zumindest ähnlich) verhalten.
Als Beispiel kann man hier die Listen ansehen: Egal von welchem Typ die Objekte sind, die in der Liste enthalten sind, die Liste verhält sich immer gleich (Operationen: Hinzufügen, Löschen, Iterieren, Größe bestimmen, etc.)

Ich habe kürzlich für ein bestimmtes Projekt eine GUI (= graphische Benutzeroberfläche) mit den Java Swing-Klassen programmiert.

Dabei ist mir negativ aufgefallen, dass es scheinbar keine einfache Möglichkeit gibt, Elemente vernünftig untereinander anzuordnen.

Es gibt zwar massig Layout-Manager für sehr einfache oder sehr komplizierte Layouts (z.B: Elemente oben, unten, links, rechts und mittig ausrichten mit BorderLayout oder beliebig komplizierte Tabellenlayouts mit GridBagLayout).

Aber ein ganz simple Anordnung von Elementen untereinander mit jeweils wahlweise Zentrierung, linker oder rechter Ausrichtung oder Streckung über die volle Breite konnte ich irgendwie nicht so einfach erreichen.

Daher habe ich mich entschieden, einen eigenen LayoutManager zu schreiben, der diesen Aufgaben gerecht wird.

Ich kenne dieses Layout-Modell aus HTML/CSS bei Elementen, die die CSS-Eigenschaft display: block besitzen.

Hierbei werden alle Elemente untereinander angeordnet, wobei die Höhe jedes Elementes vom Element selbst bestimmt wird (über getPreferredSize()), wogegen wie Breite normalerweise auf die volle Breite des Containers gestreckt wird.
Der Container ist außerdem mindestens so breit, wie die minimale Breite des breitesten Elements, so dass alle Elemente korrekt angezeigt werden können (es empfiehlt sich, dieses Layout in Kombination mit einer JScrollPane zu benutzen)

Für einzelne Elemente sind außerdem noch die vertikalen Ausrichtungen Zentriert, Linksbündig und Rechtsbündig möglich.

Zuletzt lassen sich auch noch die Abstände zwischen den Elementen und zum Rand (“margin”) frei einstellen.

Durch diesen Aufbau ist es leicht möglich, eine listenähnliche Struktur mit heterogenen Elementen (z.B: für einen Report mit Controls, Textblöcken und Bildern) zu erstellen.

Dieser LayoutManager ist kompatibel mit allen Java-Versionen seit Java 1.4 (daher: keine generics!)

Zur Anschauung ist noch eine Demo-Klasse vorhanden.

Code auf Github

Wenn man dynamische Web-Applikationen programmieren möchte, stehen einem eine große Auswahl an Technologien zur Verfügung. Sehr verbreitet ist vor allem im Business-Bereich die Java-Servlet-Technologie.

Üblicherweise ist an vordester Front ein gewöhnlicher Webserver (z.B. Apache HTTPD) vorgeschaltet, der eingehende HTTP-Requests zunächst verarbeitet.

Verweist der Request auf eine dynamische Resource (also eine Seite der Web-Applikation), so wird der Request an den Servlet-Container (z.B. Apache Tomcat) weitergeleitet und dort von dem zugehörigen Servlet verarbeitet.