Kolumne

Alles valide? Bean Validation in POJOs mittels aspektorientierter Programmierung

Wir berichteten im Rahmen dieser Kolumne bereits über die Neuerungen von Bean Validation 1.1. Besonders erwähnenswert war und ist dabei das neue Feature der Method Validation. Leider ist die Integration dieses Features noch nicht sehr weit vorangeschritten. Bisher ist es nur bei CDI-Beans möglich, sich darauf zu verlassen, dass z. B. ein Parameter, der mit @NotNull annotiert ist, auch wirklich niemals null ist. In allen anderen Situationen hilft es normalerweise nur, die Method Validation aus dem Code heraus „von Hand“ aufzurufen. In dieser Kolumne wollen wir eine alternative Möglichkeit vorstellen. Damit ist es möglich, in beliebigen POJOs auf Method Validation zu setzen.

Testen im Kontext: Integration Testing in Java EE

„Der Begriff Integrationstest bezeichnet […] eine aufeinander abgestimmte Reihe von Einzeltests, die dazu dienen, verschiedene voneinander abhängige Komponenten eines komplexen Systems im Zusammenspiel miteinander zu testen.“ (Wikipedia). Wie kann ich aber eine Menge an abhängigen Komponenten (also in Java EE z. B. EJBs oder CDI-Beans) gemeinsam testen, ohne das Ganze gleich auf meinem Testserver deployen zu müssen? Das Problem ist klar: Moderne Enterprise-Anwendungen basieren auf Dependency Injection. Das bedeutet, dass der Container die Abhängigkeit zwischen den Komponenten auflöst und gegenseitig in die Komponenten injiziert.

Java-Trickkiste: Der JIT-Compiler von Hotspot

Die Hotspot-JVM liest Class-Dateien ein und führt das entsprechende Java-Programm aus. An irgendeiner Stelle „kompiliert“ sie das Programm noch einmal und wendet dabei ausgefeilte Verfahren an, sodass Java-Programme bemerkenswert schnell laufen. Das ist in etwa das, was man beim Entwickeln von Geschäftsanwendungen über den JIT-Compiler wissen muss. Wenn man aber z. B. performancekritischen Code schreibt oder einfach nur neugierig ist, lohnt sich ein Blick hinter die Kulissen.

Reduce to the Max: Microservices

Es gibt wohl kaum ein Thema in der Softwareentwicklung, das derzeit so heiß diskutiert wird wie die Wunderwelt der Microservices. Von „einfach genial“ bis hin zu „alter Wein in neuen Schläuchen“ trifft man auf die unterschiedlichsten Meinungen. Nicht selten begründen sich dabei die verschiedenen Einstellungen der Diskutanten schon in der Auffassung, was sich denn genau hinter dem Begriff „Microservices“ verbirgt. Grund genug für EnterpriseTales, einen Blick hinter die Kulissen zu wagen.

Docker rockt Java: EC2 Container Service mit AWS

Bis vor Kurzem mussten Entwickler noch selbst Docker auf ihren EC2-Instanzen in Amazon Web Services installieren und das Management der Container vollständig selbst übernehmen. Mit der Einführung der Unterstützung von Docker in Elastic Beanstalk und OpsWorks wurde der Aufwand für die Nutzung von Containern bereits reduziert. Auf der Konferenz „AWS re:Invent 2014“ hat Amazon den neuen EC2 Container Service vorgestellt, der die Hürde für das Betreiben von Software in Docker-Containern noch einmal signifikant senkt.

Docker mit Maven steuern

Docker bietet eine alternative Möglichkeit, Java-Applikationen zu bauen und in Produktion zu setzen. Bisher wurden Java-Enterprise-WARs oder -EARs in vorinstallierte Java-EE-Server deployt. Jetzt können die Anwendungen direkt komplett, inklusive des Servers, in Docker-Containern ausgeliefert werden. Der Ausführungskontext wird gleich mit verpackt, und lästige Anpassungen entfallen. Mit dieser Methode können die Container überall laufen und schon in der Entwicklung für den Betrieb zusammengestellt werden.

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.