Kolumne

Docker für Java-Entwickler

Infrastruktur macht die Ausführung unserer Software erst möglich. Der Markt erwartet von uns eine schnellere Lieferung von Änderungen, eine höhere Qualität und mehr Flexibilität im Betrieb. Beim Einsatz von Java als Basis unserer Anwendungen haben wir oft mit der fehlenden Einheitlichkeit unserer Produktions-, Test- und Entwicklungsumgebungen zu kämpfen. Der Anspruch „… runs anywhere“ hat leider in der Praxis seine Tücken. Zum Produkt gehören eben nicht nur das Java-Programm, sondern eine Vielzahl weiterer Infrastrukturkomponenten.

Wenn Scopes fremdgehen: Mehr Spaß mit CDI-Scopes

Eine klassische Webarchitektur besteht mindestens aus einer Serviceschicht, die in CDI @ApplicationScoped ist, und einer darüberliegenden Controllerschicht, deren Beans je nach Anwendungsfall @RequestScoped, @ConversationScoped oder @SessionScoped sind und die Services injiziert bekommen. So weit, so normal. Dank des CDI-Proxy-Mechanismus ist aber auch der umgekehrte Weg möglich, also die Injection einer @RequestScoped, @ConversationScoped oder @SessionScoped Bean in eine @ApplicationScoped Bean (also z. B. in den Service). Auf diese Weise lässt sich z. B. ein @RequestScoped EntityManager, der gerade angemeldete Benutzer oder der aktuelle Mandant überall injizieren, wo sie benötigt werden – jedenfalls in der klassischen Webanwendung. Sobald man aber asynchron unterwegs ist, ergeben sich einige Schwierigkeiten, die wir in dieser Kolumne näher beleuchten und umschiffen wollen.

Aus der Java-Trickkiste: Hotspot-Schalter

Die meisten Java-Entwickler wissen, wie man bei einer JVM die maximale Heap-Größe setzt oder – zumindest vor Java 8 – den Speicher für die Permanent Generation vergrößert. Aber Hotspot hat eine Vielzahl weiterer Einstellmöglichkeiten, und um die geht es diesen Monat.

Was erwartet uns in Java EE 8?

Kaum haben wir uns an die neuen Features von Java EE 7 gewöhnt, ist auch schon die nächste Version des Java-Enterprise-Standards am Horizont sichtbar. Pünktlich zur JavaOne 2014 wurde der zu Java EE 8 gehörende JSR 366 vom Java EE Executive Committee (EC) einstimmig angenommen. Grund genug, einmal zu schauen, was uns zum geplanten Releasetermin in Q3 2016 so alles erwartet.

Bytecode-Analyse im Eigenbau

Im Java Magazin 12.2014 haben wir uns angesehen, wie man den Classpth scannen kann, ohne Klassen in die JVM zu laden und dann Reflection zu verwenden. Jetzt gehen wir wie angekündigt einen Schritt weiter und analysieren Aufrufketten auf Basis des Bytecodes. Als Beispiel dafür, was damit möglich ist, erstellen wir ein Ranking der am häufigsten aufgerufenen Methoden und suchen die Methoden mit der größten inneren Komplexität heraus. Wie schon letzten Monat verwenden wir dazu die Bytecode-Bibliothek asm.

Classpath-Scan im Eigenbau [Aus der Java-Trickkiste]

Viele moderne Frameworks können zur Initialisierung den Classpath nach annotierten Klassen durchsuchen (z. B. EJB 3, JPA, Spring und sogar Servlet-API 3!). Ich halte diesen Architekturstil für problematisch (Startzeit, Testbarkeit, Security etc.), aber das ist ein Thema für eine andere Kolumne. Und egal wie man zu ihnen steht, Classpath-Scans begegnen einem heutzutage auf Schritt und Tritt – ein Grund, sich die Mechanismen dahinter anzuschauen.

Java EE 8 meets MVC: ein Blick in die Kristallkugel

Für viele überraschend hat Oracle für Java EE 8 einen neuen Java Specification Request zur Ergänzung des aktuellen Web-Development-Stacks angekündigt: MVC 1.0. Obwohl bisher kaum Details zum neuen API bekannt wurden, spaltet der JSR 371 schon jetzt die Community. Grund genug, einen Blick hinter die Kulissen zu wagen.

Aus der Java-Trickkiste: Performancemythen

Performance ist ein beliebtes Thema für Entwicklerstammtische. Echte und vermeintliche Best Practices werden – oft als Teil persönlicher Erlebnisse – von Programmierergeneration zu Programmierergeneration weitergegeben. Diesen Monat nehme ich eine Reihe solcher Meinungen unter die Lupe, die mir in Projekten und bei Reviews immer wieder begegnen.

Java-Trickkiste: Patterns zum Instanziieren von Klassen

Diesen Monat stelle ich einige Patterns zum Instanziieren von Klassen vor. Bei Coaching und Codereviews erlebe ich, dass viele Entwickler sich weitgehend auf Default-Konstruktoren und DI-Frameworks beschränken – was nicht per se schlecht ist, aber es gibt für manche Situationen bessere Alternativen. Wenn das eine oder andere bekannt vorkommt: umso besser. Es geht hier nicht darum, bahnbrechende neue Ideen zu präsentieren, sondern ein paar im Prinzip bekannte Lösungen in Erinnerung zu rufen.

Knigge für Softwarearchitekten: Der Domäniker

Eine der empfohlenen Entwicklungsmethodiken für Softwarearchitekturen ist Domain-driven Design (Literatur dazu siehe hier, hier und hier). Dieses sieht vor, die Konzepte der Domäne, d. h. die Entities, die verarbeitet werden und die Services, die fachlich gebraucht werden, zuerst zu modellieren und dann möglichst unverändert eins zu eins im Sourcecode zu verankern. Das klingt einfach und fast selbstverständlich. Je stärker die Codestruktur mit der realen Welt übereinstimmt, desto leichter sind die Wartbarkeit und die Erweiterbarkeit der Software.

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.