Lars Röwekamp

Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.

@mobileLarson

Beiträge dieses Autors

Enterprise Tales: Pragmatic REST

„To REST or not to REST“, das ist hier die Frage. Eines ist sicher, nur weil ich JSON oder XML Payload via HTTP an einen Server sende oder von eben diesem empfange, habe ich es sicherlich noch nicht zwangsweise mit einem RESTful API zu tun. Was also genau macht eine REST-Schnittstelle aus? Und ab wann kann man sie als wirklich gut gelungen bezeichnen? Spätestens bei dieser Frage gehen die Meinungen stark auseinander.

Enterprise Tales: Welches JavaScript-Framework passt zu mir?

Noch vor wenigen Jahren von vielen Enterprise-Entwicklern als Unheil bringendes Voodoo abgetan, gewinnt JavaScript in modernen Webanwendungen mehr und mehr an Bedeutung. Entsprechend groß ist auch der Zoo an wunderverheißenden Frameworks, aus denen es das passende zu wählen gilt. Wie so oft im Leben gilt leider auch hier: „Wer die Wahl hat, hat die Qual“.

Enterprise Tales: MVC 1.0, das Aus für JSF?

Dass Java EE 8 mit einem neuen, MVC-basierten Webframework (JSR 371) aufwarten wird, sollte sich mittlerweile herumgesprochen haben. Genauso wie die Tatsache, dass nicht wenige Mitglieder der Java-Community den Sinn eines weiteren Webframeworks innerhalb des Enterprise-Java-Standards in Frage stellen. Zum einen bekommt der bisherige Platzhirsch JSF Konkurrenz aus den eigenen Reihen. Zum anderen gibt es bereits MVC-Alternativen außerhalb des Standards. Muss das neue Framework also wirklich sein?

JavaOne Tagebuch – Tag 5 „The final Chapter“

Heute war also der letzte Konferenztag der JavaOne. Auf meiner Agenda stand natürlich die traditionelle JavaOne Community – a.k.a. Comedy – Keynote, sowie die eine oder andere Session zum Thema Microservices.

JavaOne Tagebuch – Tag 3 a.k.a. Tag 4

Als ich heute Morgen aufgewacht bin, hatte ich kurz die Befürchtung, einen kompletten Tag verschlafen zu haben. In meiner Inbox befand sich eine eMail von Oracle mit dem Betreff „Welcome to the JavaOne – Day 4“. Dabei war nach meiner Zeitrechnung doch eigentlich erst Tag 3 an der Reihe. O.k. ich war gestern noch mit ein paar Freunden das eine oder andere Bier trinken – aber so wild war es doch nun wirklich nicht. Scheinbar zählt Oracle den Sonntag mit seinen Workshops und den University-Veranstaltungen bereits als ersten Tag der Konferenz. Dann also herzlich willkommen zu Tag 4 der JavaOne.

JavaOne Tagebuch – Tag 2

Getreu dem Motto „Reduce to the Max“ habe ich mir für heute einige Sessions rund um das Themen Java für IoT und Mobile Devices, vorgenommen. Es war schon interessant zu sehen, welche unterschiedlichen Ansätze es derzeit in der Java Welt für diese beiden Anwendungsgebiete gibt. Nicht unbedingt überraschend spielt dabei natürlich auch Java ME Embedded weiterhin – oder sollte ich besser sagen wieder – eine Rolle.

JavaOne Tagebuch – Tag 1

Wie schon in den letzten Jahren, verteilen sich auch dieses Jahr die verschiedenen Veranstaltungen der JavaOne auf mehrere benachbarte Hotels. Auch wenn diese recht dicht beieinander liegen, kommen bei einer ungünstigen Auswahl an Sessions schnell 10km Fußmarsch am Tag zusammen. Also heißt es, entweder Laufschuhe an und die Health App meiner Apple Watch glücklich machen, oder mich alternativ vorher auf ein Themengebiet und somit auch auf ein Hotel festlegen. Ich habe mich für zweiteres entschieden und mir für heute – mit wenigen Ausnahmen – einige Sessions rund um das Thema „Enterprise Java“ auf die Agenda gelegt.

JavaOne Tagebuch – Tag 0

„Celebrating 20 years of Java“, dieses Motto wird mir in den kommenden Tagen wohl noch des Öfteren begegnen. Kein Wunder, denn ich bin live auf der JavaOne in San Francisco und werde von dort täglich einen kleinen „Stimmungsreport“ liefern.

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.