© Excellent backgrounds/Shutterstock.com
Java Magazin
Runtimes im Überblick

Konkurrenz belebt das Geschäft

Im folgenden Artikel geben wir einen Überblick über die MicroProfile Runtimes, die das Technology Compatibility Kit (TCK) für die jüngeren MicroProfile-Releases zum Stand Mitte Dezember bestanden haben: Thorntail, TomEE, Payara Micro, Open Liberty, KumuluzEE und Helidon. Zahlreiche weitere Runtimes, die die Spezifikation nur in Teilen erfüllen, berücksichtigen wir hierbei nicht.

Mikhail Golubev , Tim Zöller


Seit etwas über zwei Jahren treibt die Eclipse Foundation die MicroProfile-Spezifikation in einem schwindelerregenden Tempo voran: Seit Version 1.0 im Jahr 2017 wurden bereits zehn Releases veröffentlicht. Die Maintainer der gängigen MicroProfile Runtimes müssen dieses Tempo mitgehen, eine Spezifikation ohne Implementierungen kann schließlich von niemandem verwendet werden. Bei den meisten dieser Implementierungen handelt es sich um Ableger von Application-Servern, die im Schnitt nur alle drei bis vier Jahre eine neue Java-EE-Spezifikation unterstützen mussten. Ein gründlicher Blick auf die Runtimes lohnt sich, bevor man mit MicroProfile loslegen möchte: Wie reaktionsschnell sind die Projekte? Welche aktuellen MicroProfile-Versionen unterstützen sie? Wer treibt die Entwicklung voran, und wie sieht es mit Support aus?

Warum so viele Runtimes?

Um zu verstehen, warum solch eine hohe Zahl von MicroProfile Runtimes existiert, muss man sich noch einmal in Erinnerung rufen, dass MicroProfile selbst keine lauffähige Implementierung ist. Es handelt sich vielmehr, ähnlich wie bei Jakarta EE, um eine Sammlung von Spezifikationen, die zu einer übergreifenden Spezifikation zusammengefasst sind. Genau wie bei Jakarta EE müssen Projekte diese Spezifikationen implementieren, um sie für Benutzer verfügbar zu machen. Das Ziel dahinter ist, Benutzern eine Vielzahl von Alternativen und damit eine Auswahl anzubieten. Während sich Entwickler bei der Benutzung von Spring an die einzige existierende Implementierung binden, können Sie als Nutzer des MicroProfile-Standards von der Implementierung unabhängig bleiben. Verliert beispielsweise ein Betreiber das Interesse daran, seine Runtime weiterzuentwickeln, ist es mit verhältnismäßig wenig Aufwand möglich, seine Applikation zu einer anderen Implementierung umzuziehen.

Es ist gängige Praxis, dass Applikationen lediglich über eine provided-Abhängigkeit gegen MicroProfile verfügen und von der eigentlichen Runtime getrennt sind (Listing 1). Diese stellt dann die Implementierungen der einzelnen Spezifikationen zur Laufzeit bereit. Hierfür gibt es zwei Möglichkeiten: Entweder wird die Applikation zusammen mit der jeweiligen Implementierung in ein ausführbares Fat JAR gepackt oder sie wird zu einem WAR gepackt und nachträglich auf einer MicroProfile Runtime deployt. Nach dieser Theorie sollte es also möglich sein, eine MicroProfile-Anwendung ohne Anpassungen mit verschiedenen Runtimes zu betreiben. Die meisten Runtimes liefern Funktional...

Java Magazin
Runtimes im Überblick

Konkurrenz belebt das Geschäft

Im folgenden Artikel geben wir einen Überblick über die MicroProfile Runtimes, die das Technology Compatibility Kit (TCK) für die jüngeren MicroProfile-Releases zum Stand Mitte Dezember bestanden haben: Thorntail, TomEE, Payara Micro, Open Liberty, KumuluzEE und Helidon. Zahlreiche weitere Runtimes, die die Spezifikation nur in Teilen erfüllen, berücksichtigen wir hierbei nicht.

Mikhail Golubev , Tim Zöller


Seit etwas über zwei Jahren treibt die Eclipse Foundation die MicroProfile-Spezifikation in einem schwindelerregenden Tempo voran: Seit Version 1.0 im Jahr 2017 wurden bereits zehn Releases veröffentlicht. Die Maintainer der gängigen MicroProfile Runtimes müssen dieses Tempo mitgehen, eine Spezifikation ohne Implementierungen kann schließlich von niemandem verwendet werden. Bei den meisten dieser Implementierungen handelt es sich um Ableger von Application-Servern, die im Schnitt nur alle drei bis vier Jahre eine neue Java-EE-Spezifikation unterstützen mussten. Ein gründlicher Blick auf die Runtimes lohnt sich, bevor man mit MicroProfile loslegen möchte: Wie reaktionsschnell sind die Projekte? Welche aktuellen MicroProfile-Versionen unterstützen sie? Wer treibt die Entwicklung voran, und wie sieht es mit Support aus?

Warum so viele Runtimes?

Um zu verstehen, warum solch eine hohe Zahl von MicroProfile Runtimes existiert, muss man sich noch einmal in Erinnerung rufen, dass MicroProfile selbst keine lauffähige Implementierung ist. Es handelt sich vielmehr, ähnlich wie bei Jakarta EE, um eine Sammlung von Spezifikationen, die zu einer übergreifenden Spezifikation zusammengefasst sind. Genau wie bei Jakarta EE müssen Projekte diese Spezifikationen implementieren, um sie für Benutzer verfügbar zu machen. Das Ziel dahinter ist, Benutzern eine Vielzahl von Alternativen und damit eine Auswahl anzubieten. Während sich Entwickler bei der Benutzung von Spring an die einzige existierende Implementierung binden, können Sie als Nutzer des MicroProfile-Standards von der Implementierung unabhängig bleiben. Verliert beispielsweise ein Betreiber das Interesse daran, seine Runtime weiterzuentwickeln, ist es mit verhältnismäßig wenig Aufwand möglich, seine Applikation zu einer anderen Implementierung umzuziehen.

Es ist gängige Praxis, dass Applikationen lediglich über eine provided-Abhängigkeit gegen MicroProfile verfügen und von der eigentlichen Runtime getrennt sind (Listing 1). Diese stellt dann die Implementierungen der einzelnen Spezifikationen zur Laufzeit bereit. Hierfür gibt es zwei Möglichkeiten: Entweder wird die Applikation zusammen mit der jeweiligen Implementierung in ein ausführbares Fat JAR gepackt oder sie wird zu einem WAR gepackt und nachträglich auf einer MicroProfile Runtime deployt. Nach dieser Theorie sollte es also möglich sein, eine MicroProfile-Anwendung ohne Anpassungen mit verschiedenen Runtimes zu betreiben. Die meisten Runtimes liefern Funktional...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang