Kolumne

Die Systematischverbesserin [Knigge für Softwarearchitekten]

Oftmals ist die Forderung nach Verbesserung von Software eine Folge aus zu hohen Kosten von Änderungen oder Erweiterungen – denn unsere (fachlich oder betriebswirtschaftlich motivierten) Auftraggeber interessiert die innere Qualität von Systemen oftmals nur wenig. Veränderung von Software zum Besseren hin ist daher meist ein langwieriger Prozess, den Sie systematisch und schrittweise angehen müssen.

Multi-Browser-Tab-Support in Java EE 7

Webentwickler kennen das Problem. Bei der Umsetzung bestimmter Use Cases (z. B. Wizards) ist es notwendig, Daten über mehrere Requests hinweg vorzuhalten. Vor Java EE 6 gab es da nur die Möglichkeit, die Daten @SessionScoped abzulegen. Wenn aber der Benutzer die Webanwendung in zwei oder mehr Browsertabs oder -Fenstern verwendet, werden diese Daten zwischen beiden Tabs oder Fenstern geteilt, was meist zu unerwünschten Effekten führt. Der mit JSF 2.0 neu hinzugekommene View Scope (den es seit JSF 2.2 auch als CDI Scope gibt) löst das Problem, solange man sich auf einer XHTML-Seite befindet. Möchte man aber Daten (innerhalb eines Tabs) über mehrere Seiten hinweg behalten und dabei nicht auf Multi-Browser-Tab-Support verzichten, muss man zu anderen Mitteln greifen. Wir werden in dieser Kolumne betrachten, welche Möglichkeiten es da gibt und worauf man dabei achten muss.

Aus der Java-Trickkiste: Referenzen mit Sonderstatus

Dass es Weak, Soft und Phantomreferenzen gibt, ist inzwischen recht allgemein bekannt. Und man kann mit ihnen sogar praktische Probleme lösen – ein guter Grund, sie näher unter die Lupe zu nehmen. Die drei speziellen Referenztypen haben gemeinsam, dass sie von der Garbage Collection besonders behandelt werden. Das ist im C++-Quelltext der JVM fest implementiert, man kann also nicht einfach neue Arten von Referenzen mit Sonderbehandlung einführen.

Knigge für Softwarearchitekten: Die Meisterin der kleinen Schritte

Nach einigen Typen wie dem Fahnder und dem Schmutzfink, die sich mehr oder weniger professionell mit Sourcecode auseinander gesetzt haben, diskutieren wir in dieser Folge ein anderes Problem bei der Wartung existierender Systeme: Man hat Ihnen viel Code übertragen, den Sie aufrechterhalten und weiterentwickeln müssen, zu dem aber keine geeignete Dokumentation vorhanden ist. So geht es Beate, die mit Ihrem Team gerade 840 000 Zeilen C++ geerbt hat – und die nächsten Wünsche der Kunden stehen schon an.

JDBC-Treiber selbstgebaut [Java-Trickkiste]

Vor vielen Jahren hatte ich mit einem System zu tun, das bei bestimmten Eingabewerten Daten verfälscht in der Datenbank ablegte. Das Phänomen gab dem ganzen Team Rätsel auf, zumal das unser erstes Projekt mit einem O/R Mapper war und wir also keine Intuition für mögliche Fehlerursachen hatten.

Knigge für Softwarearchitekten: Der Schmutzfink

Diese Folge unserer Kolumne handelt von Schmutzfinken, einer Spezies, die so alt ist wie das Programmieren selbst. Sie besitzen einen überaus starken Überlebenswillen und lassen sich auch durch Technologiewechsel nicht aus ihrem Konzept bringen. Im Gegenteil: Mit jeder neuen Technologie, Programmiersprache oder Framework entdecken Schmutzfinken neue und kreative Möglichkeiten, ihrer Passion zu frönen.

Knigge für Softwarearchitekten: Fahndungsergebnisse

In den letzten beiden Folgen haben wir den Fahnder vorgestellt, der nach Architektur- oder Codesünden und ähnlichen Missetaten in bestehenden Systemen sucht (siehe Teil 1 „Der Fahnder“ und Teil 2 „Spuren verfolgen“). Die Fahnder suchten in den letzten Folgen nach technischen Schulden, Risiken und anderen Sünden, und zwar durch Opfer- und Zeugenvernehmung sowie Bestandsaufnahmen im Code und der Dokumentation. Sie überprüften ihre Funde durch Kreuzverhöre und schlugen für die wirklichen Sünden im Code Maßnahmen vor. Im dritten Teil diskutieren wir, wie Fahnder mit den Ergebnissen ihrer Arbeit umgehen sollten.

Überraschende Effekte mit Java Reflection

Wenn ein Feld einer Klasse final ist, muss man es im Konstruktor initialisieren. Danach behält es seinen Wert, solange das Objekt lebt. Oder doch nicht? Dieser Artikel betrachtet die Möglichkeiten, nachträglich die Werte von Feldern zu ändern, die als final deklariert sind. Man kann damit wilden Schabernack treiben. Es gibt aber auch sinnvolle Anwendungsbereiche dafür. Aber fangen wir mit der skurrilen Seite des Themas an.

Java-Trickkiste: Von Checked und Unchecked Exceptions

Ungewöhnliche Bibliotheken, überraschende Lösungen, skurrile Codeschnipsel, idiomatische Leckerbissen, Tipps und Tricks und der Blick hinter die Kulissen der verbreitetsten Programmiersprache der Welt. Das ist das Thema dieser neuen Kolumne, die sowohl für Neulinge als auch alte Hasen Wissenswertes bereithält.

Knigge für Softwarearchitekten: Ändern als Normalfall

Willkommen zu einer neuen Serie unserer Kolumne für Softwarearchitekten. In den bisherigen Folgen hatten wir Sie mit Verhaltensmustern und der Ausbildung von Softwarearchitekten traktiert. Nun geht’s in eine andere Richtung weiter: Wir beleuchten das Thema „Ändern bestehender Software“ aus architektonischer Sicht.

Java-EE-Architekturen und JPA: Verwendung des EntityManager im Java-EE-Stack

In der letzten ET-Kolumne haben wir gelernt, wie man mittels JPA Use-Case-bezogen Daten laden kann – oder das Laden bewusst unterdrückt. Das Zauberwort hier heißt „Lazy Loading“. Neben den bereits in JPA 2.0 vorhandenen Möglichkeiten sind wir dabei auch auf das in JPA 2.1 kommende Feature der Fetch bzw. Load Graphs eingegangen. Heute wollen wir einen Schritt weiter gehen und analysieren, wie verschiedene Architekturen den Umgang mit Lazy Loading beeinflussen können und welche Möglichkeiten es im Umkehrschluss gibt, Lazy Loading im gesamten Applikationsstack zu berücksichtigen und sinnvoll verwendbar zu machen.

Was du später kannst besorgen: Lazy Loading in JPA 2.1

In der letzten Kolumne haben wir einen Blick über den Java-EE-Standard-Tellerrand hinaus geworfen und das alternative Query-API „QueryDSL“ vorgestellt. Heute kehren wir wieder zurück in den JPA-Standard. Dort gibt es seit dem 22.05.2013 das „Final Release“ der Version 2.1. Und dieses bringt ein interessantes neues Feature im Bereich Lazy Loading mit sich. Bei diesem neuen JPA-Feature geht es darum, Daten erst zu einem späteren Zeitpunkt zu „besorgen“, nämlich dann, wenn sie tatsächlich gebraucht werden. Dass dieses Feature auch seine Tücken hat und welche Neuerung JPA 2.1 hier bringt, wollen wir im Folgenden zeigen.