Kolumne: EnterpriseTales

„Is Java 8 Enterprise-ready?“ oder: „Is Enterprise ready for Java 8?“

Arne Limburg, Lars Röwekamp

© Shutterstock.com/iQoncept

Java 8 ist da. Damit einher kommen einige neue Sprachfeatures und APIs, von denen die Lambda Expressions wohl die berühmtesten sind. Aber was bedeutet das für den allgemeinen Enterprise-Entwickler? Ab wann können die Features und APIs im Enterprise-Umfeld eingesetzt werden? Wir nehmen das aktuelle Major-Release der Java-Plattform zum Anlass, diese Fragen zu beantworten. In dieser und den nächsten Kolumnen werden wir einen Blick auf die Neuerungen werfen und sie in den Kontext von Enterprise-Java setzen.

Java 8 erst mit Java EE 8?

Offiziell wird Java 8 im Enterprise-Umfeld erst von Java EE 8 unterstützt. Und für Java EE 8 gibt es bisher nur einen Entwurf (siehe „Java EE 8: Update zu Release-Plan und Feature-Set“). Wann also Java 8 offiziell von Java EE unterstützt wird, steht in den Sternen. Das heißt aber nicht, dass ein Application Server nicht trotzdem mit Java 8 lauffähig wäre. Schließlich ist ja Java abwärtskompatibel, oder etwa nicht?

Java 8 im Application Server

Wer im Java-Enterprise-Standard entwickeln und deployen will, braucht einen Application Server. Soll die Entwicklung mit Java 8 geschehen, muss also auch der Application Server Java-8-kompatibel sein. Machen wir also den Test. Wir starten mit der Java-EE-Referenzimplementierung, dem GlassFish 4. Das Starten mit Java 8 funktioniert problemlos, und eine Log-Ausgabe bestätigt auch, dass der Server tatsächlich auf Java 8 läuft.

Das Deployment und der Start einer Anwendung, die mit Java 8 kompiliert ist, funktioniert auch noch – solange man keine Java-8-Sprachfeatures verwendet. Versucht man Code zu deployen, der z. B. eine Lambda Expression enthält, dann steigt der Server beim Deployment mit einer Exception aus, die darauf hindeutet, dass eine der Bibliotheken, die den Bytecode scannt, wohl noch nicht mit Java-8-Byte-Code umgehen kann. An dieser Stelle brechen wir den Versuch ab. Eine kurze Google-Suche ergibt, dass mit weiteren Problemen zu rechnen ist. So scheint es der Fall zu sein, dass EclipseLink (der JPA-Provider des GlassFish) Klassen mit Java-8-Features still ignoriert. Zwischenfazit: Mit dem GlassFish 4 lassen sich aktuell keine (echten) Java-8-Anwendungen entwickeln und betreiben.

Wenden wir uns also dem nächsten Open-Source-Anwendungsserver zu: WildFly 8. Hier deuten bereits die Release Notes darauf hin, dass Java 8 unterstützt wird.

Wie erwartet, lässt sich der WildFly problemlos mit Java 8 starten und bestätigt auch per Log-Ausgabe, dass er mit Java 8 läuft. Das Deployment unserer kleinen Testanwendung funktioniert auch. Natürlich können wir nicht jedes kleinste Feature testen, um zu überprüfen, ob Java 8 von jedem im WildFly verwendeten Framework vollumfänglich unterstützt wird. Aber das Ergebnis reicht, um sagen zu können, dass mit dem WildFly eine Entwicklung mit Java 8 möglich ist.

Bytecode-Scanning und Co.

Aber woran liegt es, dass einige Server und Frameworks Java 8 unterstützen und andere trotz Abwärtskompatibilität nicht? Enterprise-Java-Frameworks basieren mittlerweile alle darauf, dass sie die Java-Klassen beim Hochfahren scannen, um z. B. Annotations auszuwerten. Einige Frameworks müssen darüber hinaus dynamisch Proxys von Klassen erzeugen oder den Bytecode verändern, um Funktionalitäten wie z. B. Transaktionen (im EJB-Umfeld) und Lazy Loading (im JPA-Umfeld) realisieren zu können. Das reine Auslesen von Annotations könnte noch über das Reflection-API von Java realisiert werden, das abwärtskompatibel ist. Geht es aber an die Bytecode-Veränderung, so ist man mit Java-Bordmitteln aufgeschmissen. Die Frameworks greifen dann auf spezielle Bibliotheken zurück, mit denen Bytecode generiert werden kann (cglib, Javassist, ASM). Folglich sind sie auch darauf angewiesen, dass diese Bibliotheken mit Java-8-Bytecode umgehen können. Und das kann ASM z. B. erst seit der Version 5. Um Java 8 im Enterprise-Umfeld vollumfänglich einsetzen zu können, müssen die jeweils verwendeten Frameworks also ihre Bytecode-Bibliotheken aktualisieren.

Wird keine Bytecode-Veränderung benötigt, wie zum Beispiel in den klassischen Webcontainern wie Tomcat oder Jetty, so können Java-8-Features dank Abwärtskompatibilität bereits heute verwendet werden – vorausgesetzt, der Container wird mit einer Java-8-Runtime gestartet.

Aber natürlich muss auch hier darauf geachtet werden, dass die verwendeten Frameworks Java 8 unterstützen. Mit gutem Beispiel voran geht diesbezüglich das Spring Framework. Hier hat man bereits zu Beginn der Entwicklung von Spring 4 darauf geachtet, dass es Java-8-kompatibel ist. Das Framework kann also schon heute mit Java 8 verwendet werden.

Fazit

Will man im Enterprise-Umfeld mit Java-8-Sprach-Features entwickeln, so ist das aktuell nicht einfach. Von den Open-Source-Java-EE-Anwendungsservern ist aktuell nur der WildFly 8 in der Lage, Applikationen, die Klassen mit Java-8-Sprachfeatures enthalten, zu deployen.

Im Framework-Bereich hängt es sehr stark von den verwendeten Bytecode-Bibliotheken ab. So unterstützt ASM Java 8 erst ab der Version 5.0. Das Spring Framework zum Beispiel hat von vornherein bei der Entwicklung der Version 4 auf Java-8-Kompatibilität gesetzt. Es kann daher problemlos mit Java 8 eingesetzt werden.

Wer in seiner Entwicklung sowieso nicht auf einen Application Server setzt, sondern wem ein Webcontainer (Tomcat oder Jetty) reicht, der braucht nicht auf Java 8 zu verzichten. Da reine Webcontainer normalerweise gar keine Bytecode-Manipulation durchführen, können hier auch Klassen deployt werden, die Java-8-Features enthalten. Aber auch hier gilt es darauf zu achten, dass alle in der Applikation verwendeten Bibliotheken Java 8 unterstützen.

Wie wir sehen, die ersten Schritte in Richtung Java 8 im Enterprise-Umfeld sind getan. Bis Java 8 von allen Containern und Frameworks vollumfänglich unterstützt wird, ist es aber noch ein weiter Weg, der sicherlich bis zum Release von Java EE 8 andauern wird. Das soll uns aber nicht davon abhalten, bereits jetzt zu betrachten, wie sich die Java-8-Features auf die Enterprise-Entwicklung auswirken, und genau das werden wir in den nächsten Kolumnen tun. In diesem Sinne: Stay tuned.

Aufmacherbild: Ready word and question mark prepared for a test, trip or other special or important event von Shutterstock / Urheberrecht: iQoncept

Geschrieben von
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.
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.
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "„Is Java 8 Enterprise-ready?“ oder: „Is Enterprise ready for Java 8?“"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Veit Weber
Gast

Erwähnenswert ist, dass Glassfish 4.1 (ehemals 4.0.1) Mitte August erscheinen soll und Java 8 unterstützen wird.
(https://blogs.oracle.com/theaquarium/entry/spotlight_on_glassfish_4_1)

Veit Weber
Gast

Erwähnenswert ist, dass Glassfish 4.1 (ehemals 4.0.1) Mitte August erscheinen soll und Java 8 unterstützen wird.
(https://blogs.oracle.com/theaquarium/entry/spotlight_on_glassfish_4_1)