Arne Limburg

Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Beiträge dieses Autors

Wie können APIs sinnvoll weiterentwickelt werden, ohne Abwärtskompatibilität zu vernachlässigen?

Nicht selten ist die Weiterentwicklung von APIs eine so große Herausforderung für Entwickler, dass sie versuchen, ganz darauf zu verzichten und ein einmal veröffentlichtes API möglichst stabil zu halten. Das ist grundsätzlich zunächst keine schlechte Idee. Allerdings führen neue Anforderungen und die damit verbundene Weiterentwicklung der Implementierung schnell dazu, dass API und Businesslogik auseinanderlaufen.

EnterpriseTales: Java und die reaktive Programmierung – ein neues Programmierparadigma

In meiner letzten Kolumne zu zehn Jahren JPA habe ich darüber geschrieben, wie die Spring-Hibernate-Community um das Jahr 2006 für einen Paradigmenwechsel in Enterprise Java gesorgt hat. Naturgemäß lag in der genannten Kolumne der Fokus auf der Veränderung, die JPA gebracht hat. Bis zu dem Zeitpunkt entstanden Java-Enterprise-Standards in der Regel am Reißbrett und waren hinterher für viele Anwendungsfälle untauglich.

Zehn Jahre JPA: Von einem (Standard), der auszog, Veränderung einzuleiten

Am 11. Mai 2006 wurde der EJB-3.0-Standard veröffentlicht und mit ihm die Version 1.0 des Java Persistence API, kurz JPA. Und so hatte JPA vor einem knappen Dreivierteljahr seinen ersten runden Geburtstag. Zehn Jahre sind in der IT-Welt eine halbe Ewigkeit. Wie hat der JPA-Standard diese Zeit überstanden? Wo kam er her? Was hat er bewirkt? Und welche Bedeutung hat er heute und in der Zukunft?

Need for Speed: Android-Emulator Genymotion

Es gibt wohl kaum einen Android-Entwickler, der sich nicht schon in der einen oder anderen Weise über die Emulatoren aus dem Hause Google geärgert hat. Extrem langsam, arm an Funktionalität und dazu noch buggy – viel Gutes gibt es wirklich nicht über die virtuellen Devices zu berichten. Und selbst wenn man sich an die in [1] beschriebenen Schritte zum „Pimpen“ der Emulatoren hält, kommt nicht wirklich Freude auf. Wieso also nicht einmal eine Alternative ausprobieren?

Unit Tests mit Android Studio

Seit der Einführung des Android Studios als offizielle Android-IDE hält sich vehement das Gerücht, dass eine sinnvolle Absicherung der eigenen Sourcen durch Unit Tests nur mit sehr viel Bauchschmerzen und auch nur unter Verwendung der veralteten JUnit-Version 3.x zu realisieren ist. Hatte diese Aussage in der Version 1.0 durchaus noch ihre Berechtigung, gilt spätestens seit der Nachfolgerversion 1.1 das Gegenteil.

Android Tutorial: Umstellung der Kommunikation von Pull auf Push

Mobile Anwendungen zeigen oftmals gänzlich andere Kommunikationsmuster auf als ihre Pendants aus der Webwelt. Die App öffnen, den aktuellen Status abfragen und gleich wieder schließen, und das viele Male am Tag. So in etwa sieht das typische Nutzungsverhalten aus. Nicht selten kommt es dabei durch die vielen kleinen Requests zu einer erhöhten Last auf dem Server, die so ursprünglich nicht geplant war – die damit verbundenen Probleme eingeschlossen. Eine mögliche Lösung, dem erhöhten Lastaufkommen Herr zu werden, stellt die Umstellung des Kommunikationsmusters von Pull auf Push dar.

Es tut sich was im Web: Servlet 4.0 mit HTTP/2

Mit jeder neuen Java-EE-Version gibt es auch eine neue Servlet-Version. Diese Regel gilt schon seit J2EE 1.2, und sie wird auch mit Java EE 8 Bestand haben. Der Plan lautet, dass mit Java EE 8 Servlet 4.0 ausgeliefert wird. Neu ist allerdings, dass die neue Servlet-Spezifikation auf einer neuen HTTP-Version basiert. Alle bisherigen Servlet-Versionen seit 2.3 basieren auf HTTP/1.1, das es seit 1999 gibt.

Android Runtimes im Vergleich: ART vs. Dalvik VM

Bereits zur Google IO im Juni 2014 stellte Google eine neue Runtime vor: die ART (kurz für Android Runtime). Diese wird bereits mit Android KitKat ausgeliefert. Die Standard-Runtime ist dort allerdings weiterhin die Dalvik VM. Diese kann im Einstellungsmenü aber zugunsten von ART deaktiviert werden. Mit Android 5 (Lollipop) wird die Dalvik VM nun gar nicht mehr ausgeliefert und ist komplett durch ART ersetzt worden. Worin liegt aber der Unterschied von ART zu Dalvik und was bedeutet das für den Entwickler? Diese Kolumne erläutert die Änderungen und geht auf deren Auswirkungen ein.

Version 2.0 der CDI Specification auch in Java SE nutzbar

Bisher ist CDI ein Komponentenframework, das Dependency Injection zur Verfügung stellt, allerdings nur für Java-EE-Anwendungen. Die aktuell gültige Version ist das Maintenance-Release 1.2. Wie wir bereits in der letzten Kolumne berichteten, hat die Spezifizierung von CDI 2.0 aber schon begonnen. Und sie bringt ein durchaus interessantes Feature, mit dem es möglich sein wird, CDI auch außerhalb eines Java-EE-Containers standardisiert zu benutzen. CDI soll in Java SE nutzbar werden. Wir werden in dieser Kolumne vorstellen, wie das API aussehen könnte und was noch fehlt.

Multi-Versioning: Versionsübergreifend erfolgreiche Apps entwickeln

Plant man als Android-Entwickler eine neue App, stellt sich schnell die Frage nach der angestrebten Zielgruppe bzw. den entsprechenden Zieldevices. Wegen der nach wie vor stark fragmentierten Landschaft von Android-Versionen kann das Ignorieren der einen oder anderen Version durchaus über den Erfolg der eigenen App entscheiden. Wie geht man also am besten vor, wenn möglichst viele Nutzer erreicht und gleichzeitig keine Kompromisse in User Interface und Usability eingegangen werden sollen?

Asynchrone Events in CDI 2.0

CDI ist seit der Version 1.0 in Java EE 6 der neue Enterprise-Komponentenstandard. Während es mit CDI 1.1 in Java EE 7 nur ein Minor Update gab, kann für Java EE 8 wieder mit einem größeren Entwicklungsschritt gerechnet werden. Die Spezifizierung von CDI 2.0 hat bereits begonnen. Eines der Themen, die auf der Agenda stehen, ist die asynchrone Verarbeitung von Events. Wir werfen in dieser Kolumne einen Blick auf den aktuellen Stand der Spezifikation und geben einen Ausblick darauf, was für Möglichkeiten asynchrone Events bieten.

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.

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.

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.

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.

Mobile Messaging: Google Cloud Messaging Service

Die Situation, dass eine mobile App mit einem Server kommuniziert, kommt in der Praxis recht häufig vor. Normalerweise wird die Kommunikation dabei vom Client (also der App) initiiert. Abgesehen von ein paar kleinen Stolpersteinen, etwa einer nicht vorhandenen Netzwerkverbindung, ist […]

Android Lollipop: Neue UI-Widgets

Nachdem wir in der letzten Folge gezeigt haben, welche Möglichkeiten die neuen Animationen in Android 5.0 „Lollipop“ mit sich bringen, wollen wir in der aktuellen Kolumne [zuerst erschienen im Java Magazin 11.14, Anm. d. Red.] einen Blick auf zwei neue UI-Widgets – CardView und RecyclerView – werfen und klären, ob deren Einsatz in der eigenen App zukünftig Vorteile mit sich bringen kann.