Kolumne

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.

Wie frag’ ich die Datenbank? Typsichere dynamische Abfragen mit JPA

Die Java Persistence Query Language (JPQL) ist sehr gut geeignet, statische Abfragen, die schon zur Entwicklungszeit feststehen, zu formulieren, sodass der Persistenz-Provider daraus SQL-Abfragen generieren kann. Wie sieht es aber in Situationen aus, in denen sich die Abfrage in Abhängigkeit von Laufzeitbedingungen ändert? Welche Möglichkeiten gibt es, dynamische JPA-Abfragen zu formulieren und dennoch bereits in der IDE und zur Compile-Zeit sicher zu sein, keinen Syntaxfehler eingebaut zu haben? Jeder kennt wohl den Use Case: Es gibt eine Suchmaske mit mehreren Feldern, z. B. „Vorname“ und „Nachname“. Gesucht werden soll die zugehörige Person. Eine Abfrage gegen die Datenbank muss man in Abhängigkeit davon absetzen, ob eines der Felder befüllt ist oder es beide sind. Wie kann man einen solchen Use Case mit JPA umsetzen, ohne auf Typsicherheit zu verzichten?

Enterprise Tales: Schnell, schneller, JUEL

Webanwendungen auf Basis von JavaServer Faces stehen nicht selten in dem Ruf, unnötig langsam zu sein. Als Ursache sind schnell der komplexe Lifecycle sowie der damit einhergehende Stateful-Ansatz ausgemacht. Bei genauer Betrachtung stellt sich allerdings häufig heraus, dass die klassischen Performance-Leaks an ganz anderer Stelle zu finden sind. Das JSF-Framework gilt bei Kritikern (insbesondere bei denen, die sich nicht die Mühe gemacht haben, sich intensiv damit zu beschäftigen) als schwerfällig und „oversized“. Grund hierfür ist vor allem der 6-Phasen-Lifecycle sowie der im Hintergrund verwaltete Komponenten-State. Gerne wird dabei vergessen, dass mit der Version 2.0 gleich eine ganze Reihe sinnvoller Änderungen [1] in die Spezifikation eingeflossen ist, die sich genau dieser Thematik annehmen. Wieso also nach wir vor diese Kritik?

Enterprise Tales: Apache TomEE

Passend zur JavaOne 2011 war er da, der erste offizielle JavaEE-Web-Profile-Container der Apache Software Foundation, kurz Apache TomEE. Sichtlich erleichtert gab Projektleiter David Blevins (IBM) bekannt, dass der „neue“ Server das TCK bestanden hat. Doch was genau steckt hinter dem Apache-TomEE-Container?

Enterprise Tales: Welcome to the Jungle

Was waren das noch für Zeiten, als aus Mangel an Alternativen die Wahl des richtigen Enterprise Java Frameworks zur reinen Formsache verkam. Um 2000 herum hieß die einzig akzeptable Lösung, dank „einfach“ zu nutzender APIs und standardisierter Server, J2EE. Wenige Jahre später war das Spring Framework das Maß aller Dinge. Heute dagegen sieht die Enterprise-Java-Welt schon anders aus – Welcome to the Jungle!

Knigge für Softwarearchitekten

Willkommen bei unserer neuen Kolumne, dem „Knigge für Softwarearchitekten“. Wir stellen Ihnen typische Umgangsformen dieser Spezies vor, samt- und sonders aus unserer Praxiserfahrung. Hier finden Sie in den nächsten Ausgaben eine Menge Beobachtungen zum Verhalten von Softwarearchitekten.